I've come to use more and more Python for tasks I would have used Shell in the past. Because of weird syntax with anything but simple variables or endless fiddling with quoting.

You can get a lot done quite easily and concise in Python 3, for instance with the pathlib module that has methods for recursive globbing and stuff like that.

https://docs.python.org/3.7/library/pathlib.html

The nice thing about Bash which can obviously not be said about Python is that Bash scripts will keep working (assuming whatever they call is also there of course) since Bash goes out of its way to preserve backwards compatibility. Considering its legacy, Bash can run scripts more than a decade before Python even existed.

The only other scripting language i know of that has similar backwards compatibility is Tcl. Perhaps Perl too (ignoring Perl 6 that was renamed to something else again due to it being practically a different language).

I guess it's the trade off between backwards compatibility and readability/correctness/maintainability. Both languages will have technical debt overtime. In my opinion, I would much rather have to rarely update python scripts in exchange to for peace of mind that I can fix/update the script as need be. In my experience, *sh scripts can be fragile and hard to ensure correctness.

Having migrated something recently from python2 to python3, I'll take bash. I actually ported two of the three scripts to bash, and the third one I reluctantly moved to python3 (I needed python-pil). String handling in python3 in my opinion is a tire fire compared to bash.

> Perl 6 that was renamed to something else

Indeed, it has been renamed to Raku (https://raku.org using the #rakulang tag on social media).

Python needs to be installed, maintained, and every single library will have its list of dependencies (along with breaking API changes once in a while). There's a reason Bash exists: it's everywhere by default and you know it will still work as it works now in x years.

I'm sorry, but for the type of work he is suggesting (bash script equivalent), you don't need anything besides the standard library. I cannot think of a single system I have used in recent decades that didn't come with python installed by default. For all intents and purposes, Python is as ubiquitous as bash at this point.

Balderdash and hokum. z=1 ; while test ${z} -lt 4 ; do a=${RANDOM:1:3} ; dd if=/dev/urandom count=12 bs=4 of=${a} && b=$(cat ${a}) && echo ${b:$(expr 1 + ${RANDOM} % 4):12} ; ((z++)); done

You have one tool that you know well. I have thousands of tools that I've learned daily and I wrap with a bash script..except when I need python/tcl or C. Most of what I do in python/tcl/C is truly complicated, needs to be fast or use a data structure other than an array: as it should be. Most of what I do in the shell is as simple as the userspace tools and bash will let it be. Write the one liner above in python without importing a library.

Pretty sure it's just this:

> python -c "for i in range(4): print(__import__('os').urandom(12)[__import__('random').randint(1,4):12])"

Or something like it, that bash one liner is pretty unreadable and full of side effects that may or may not be needed. A small 3 line python file would be cleaner and more readable.

TIL about Python __import__ function. Thanks!

What's the point of not importing a library/module? It's not like cheating or something.

Eh. Pros and cons.

I think most people are spoiled by being able to install anything; I work in a locked down environment and getting anything non-sanctioned in is very difficult, and the sanctioning process is tedious if nothing else.

That, and the fact that libraries are evolving- which is why we end up with horrible things like package/library version pinning.

Sure, but we're talking (with the problem at hand) about Python standard libraries that get shipped with the Python distribution and not some NPM or pip universe.

For instance the "os" module has an "urandom" function that does essentially the same as the "dd" in the bash script. Of course you could also read from the device so you wouldn't need to import "os". You would need to import "random" to get access to the random number generator, though, but it's still part of the standard library.

We use AIX at work and it didn't have Python installed.

We had to install it for a code review tool I built.

But despite Bash's weird syntax, I love how we can do very complex tasks within a few lines.

My phone and router have bash.

Even if pyhton is installed it isn't certain if it is v.2 or 3.

My router has busybox (ash), but not bash.

Neither bash nor python seem to be preinstalled on BSDs.

Sounds like Stockholm syndrome to me!

That's great, as long as you're happy with the POSIX Unix utilities (probably, wouldn't bet my life on it) and whatever Bash 3.x provides.

This can break quite fast if you rely on something from Bash 4 (released 11 years ago, still not on OS X by default), or some command-line tools that's either not installed or uses switches/functions only available in their GNU incarnations.

For anything that involves more than one file or with a line count going into triple digits, I wouldn't recommend bash. And heck, for those kind of scripts, I'd go one step further and stick with plain 'sh', just to be really sure. Bash adds little. GNU missed the train of transitioning to something like ksh93, probably because RMS thought that everyone would be using Guile once Hurd is out. (I once worked with a pretty large piece of software for packaking/administration mostly written in ksh93, as this was more palatable for commercial Unix users -- not as important these days where you won't run into AIX, HP-UX and Irix anymore)

For anything more involved than a few straightfoward lines, I'd probably still pick Perl 5. Very common, especially as some operating systems/distros have it in their core tooling (e.g. CentOS) and because it's included in git, so even available on Windows. Standard functionality is good enough and it's no big jump from sh/awk/sed. Rather do that before I depend on some obscure gawk function or gsed switch, especially as it's really hard to tell whether that's proprietary or in what version it was first introduced. Cross-browser checking is easier these days than cross-distro/unix.

Python does have a better/bigger standard library, but isn't as common and you might even run into Python 2/3 shenanigans these days.

Still, the situations where you have something moderately complex and can't install stuff should be pretty rare. Might not be able to do it for the whole system, but things like perlbrew/rbenv/nvm/pyenv-du-jour solve that mostly. At that level, Go might be an option, too.

Actually I have recently analyzed some python code that does some shell calls and if I can eliminate them with pure python.

It was quite frustrating. A lot of stuff that the shell has simple functionality for can't be done easily in python.

Examples:

* Call to chown -R. Sure, python can change file owners (os.chown()). But it has no parameter to do this recursively. You need to build a loop around it over some file iteration function.

* Call to setfacl. Can't be done with the python standard library, needs pylibacl and you can't rely on it being installed.

* Call to killall -HUP [processname]. You can send kill signals with python, but only to pids, not to process names. You'd have to parse the system process list or something like that in order to simulate.

In all cases I decided to keep the shell call, it just wasn't worth it converting that to less readable python code.

Fair enough, choosing the right tool for the job. On my own servers I can take care that the requires modules are installed and even use virtual envs for stable library versioning. This is how we do Let's Encrypt renewal because I can use a Python library for Route53 authentication that works.

Your first example could be solved with something like

[os.chown(p, uid, gid) for p in pathlib.Path('.').rglob('*')]

Obviously this is more verbose than chown but I think it's ok in a script.

Having watched people hack together utterly bizarre bash scripts with awk and grep to handle json responses I'd very much agree here.

And before someone raises jq, what % of servers already have python installed vs jq?

> And before someone raises jq, what % of servers already have python installed vs jq?

How many of those servers have something like requests installed out of the box vs needing to fetch it via a package manager or PyPI?

jq is available in Ubuntu's universe repository along with requests.

it's python, requests is one of it's many libraries for the purpose, would actually be quite concerned hiring someone who doesn't know the multiple stdlib solutions for this and still claims ability in python.

import json

import urllib.request

tough hey

I'd be as concerned with someone not opting to use what the documentation recommends[1] in lieu of the stdlib, as I would someone who puts together an awkward Bash script to parse JSON instead of just installing the 50kb package for jq.

> The Requests package is recommended for a higher-level HTTP client interface.

[1] https://docs.python.org/3/library/urllib.request.html

It's a lot easier to hire people than fire them friend.

The documentation recommends nothing of the sort, it's a direction for consumers. We all live in varied and different worlds, how many varied server environments have you been responsible for all at once? Is it really beyond your amazing programming skills to use the tools at hand in every circumstance? Perhaps it's a chance to demonstrate yet another 3rd party tool which fixes non-existent problems.

It's a few bytes difference in your script that is using requests over the numerous and plentiful stdlib options there.

Would never use python in lieu of curl/jq for json handling unless I am writing something more complicated than a shell script. catch 22.

If it gets the job done good on you.

Each to their own. Simply saying what I would look for.

Have any examples of your apt install jq script? How would you install jq on a few hundred machines also?

I'd be happy to share an example of an out of the box python script that does the same job and works virtually everywhere.

Bash was the first scripting language I became “good” in too! The skill seems to be regularly devalued in this community, and there is no surprise why (what is collaboration and maintenance for $500).

However, it’s hard to ignore why bash masters are born in the first place if better tools exist - shouldn’t the best tool win in the long run?

My take is lone wolf hackers working in corporate /_/nix constrained environment who become proficient, prolific and efficient win the corporate version of “survival of the fittest”.

I used to know someone who worked for a hugeco with really ancient proprietary unix systems. He wrote huge, complicated things in awk.

I think the experience did things to him, but he was the guy to go to for awk questions.

Google's perforce client wrapper was thousands of lines of bash for a long time. It was both amazing and terrible. It stood up to thousands of engineers and was easy to customize, if youbwerw good in bash. Fun times...

I love Python, I am a Python trainer and wrote an into book on it.

But few years ago, I finally learnt how to use shell and it blew my mind.

With a single command, I can split a really large files in 100 based on a particular column or I can aggregate and do whatever I want with a few piped commands, preview any file with sed '3p' file

Sure. I do not write 100lines of awk code, but I believe I have started utilizing some potential of bash and I don't anymore fire up Python shell and write ten lines which then someone has to maintain!

In my org, our Program manager discovered Python and he looks to replace entire unix scripts whoch do exactly what they are required to do, never fail and will work without any changes to Python.

I don't understand that.

I don't want Python to "win" because there are things you can do in bash, if you learn it correctly

Every language has its place.

I have a workflow I maintain, it takes an image from a file path or a url, converts the image to 2-bit color, adds control codes, and sends the job to the printer - and there were two other utilities did various calibration options for the printer.

So, originally it was written in python2, and used an IPP library that didnt make the leap to python3, so I ported the 'core' (downloading the image, and processing it, and adding the needed control codes) part of the job to python3, and then wrote a bash wrapper to run this script, and pipe the output to lp, it also uses $PIPESTATUS to provide intelligent error codes back to the calling application.

When I approached this, I realized that I could have ported the whole thing to bash, but the more I thought about it I realized it'd probably have greater overhead. First I'd have to run the script, then curl, then next imagemagick (which has its own issues), then insert the formatting around the image, and then run lp. I looked at it and figured python has lower overhead to do all of these things, as everything but the image handling is part of the python standard library.

There were two other scripts however, that all they do is output a bunch of strings, and send them to be printed, these were also python2 and used IPP, these however I just reimplemented in bash, and send the jobs directly to cups.

My attitude is use whatever language you feel comfortable with to accomplish the task, you can do serious programming in bash - people are incredulous at this, but the basic unix toolset is so powerful, you can do almost anything with it.

I think in bash still. I know python and php, but I still think in bash.

> Bash was the first scripting language I ever got "good" with.

Same here. However, it wasn't until I used other languages to manage systems, or glue utilities together, that I really started appreciating Bash.

Bash can be ugly and pretty gross at times, but there are some problems that can be solved quite elegantly with it.

> It also left me a bit weird when thinking about concurrency

Funny, one of the things that I like the most about Bash is how simple it makes concurrency, especially when you pair it with GNU parallel.

> Funny, one of the things that I like the most about Bash is how simple it makes concurrency, especially when you pair it with GNU parallel.

Or xargs :-)

Sub shells are something I don't think get used enough. I would love it if it was easier to spawn extra processes, particularly if those processes could be strongly sandboxed.

Who cares about overflows in your video encoder, if all it can do is make you output broken / different video?

side note -- jobs+join is not a bad thing in many cases !