The problem is most people don't want to consider themselves "serious bash scripters" but still think they can write bash, which always results in unstable and vulnerable scripts. Python on the other hand can be written by unserious python scripters and more often be at least accidentally correct. Another big issue is that the quoting, escaping and expansion rules in bash can be daunting even for serious bash scripters, with silent errors or completely different behaviour just because you forgot a : before (or was it after?) the $-

As a test, run shellcheck on any random shell-script written by these Coworkers from Christmas Past (or your own past) and it will spew serious warnings on almost every single line, run an equivalent analyzer on an equivalently unserious python file and you might in bad cases get 2 or 3 minor warnings per 100 lines.

The comparison is a bit unfair because just by getting these compiler errors and exceptions from a real language you force yourself into a more serious mental mode of programming instead of happy scripting, but that is just another argument in favor for not using bash IMO.

I agree with you, mostly, and let me point out where I don't.

1. People who don't want to consider themselves "serious bash scripts" shouldn't be writing non-trivial bash scripts unless they're okay with it turning out buggy. I agree this is a personal standards thing, and reality is often less simple and more lenient than that.

2. The "compiler errors and exceptions" that you speak of in regards to Python also have equivalents in Bash. Agreed, they're still optional and non-"serious bash scripters" don't often know of them. Which is why I make my coworkers use them when I review their code.

3. There are classes of bugs that would happen in Python (and Go, from my experience) that wouldn't happen in bash, simply because they are in areas where bash shines. At work, I've seen process management and stdio management bugs — some of which have bit us in the field — simply because the non-bash language (Go) has a weird affinity to its child processes, or it (both Python and Go) defaults to not wiring up the stdio of child processes. In the latter case, the proper thing for the developer to do was the same as with bash: read the documentation. Most of our process management code is now in bash (because it's simple and safe) and systemd (because it's thorough and absolute).

In my experience, those kinds of shell scripts get written by people who needed automate something quickly and didn't have (or at least perceive) any other language available besides maybe Perl. They're either Unix admins without much programming experience or they're part-time programmers who primarily work in some other language and just don't have the familiarity with Python or Ruby needed to write a good glue script.

But they know how to accomplish this task interactively in the shell, so scripting what they're already doing (or already know how to do) seems like the natural next step. So you wind up with an imperative shell script that's basically a long, flat sequence of commands with some logic and variables sprinkled in haphazardly as they realized they needed it.

Due to the organic way these scripts often emerge, it's not like advocating Python is an easy sell. By the time they think to consider alternatives, the shell version already exists.

I agree. And I agree with your bash 'whitelist'. I'd also add a hard blacklist for any serious string manipulation. A series of awks and seds look clever but they are quite annoying to deal with.

If it's just a bunch of cuts or tr, sure.

And it's SO MUCH MORE expensive to fork all those processes. Just use a real language, please.

"A series of awks and seds look clever but they are annoying to deal with."

Would the following be annoying for you to deal with?

   #!/bin/sh
   sed 's/#.*//' \
   | sed 's/:/#/g' \
   | cat AMD64 - \
   | ./qhasm-ops \
   | ./qhasm-regs \
   | ./qhasm-fp \
   | ./qhasm-as \
   | sed 's/%32/d/g' \
   | sed 's/%raxd/%eax/g' \
   | sed 's/%rbxd/%ebx/g' \
   | sed 's/%rcxd/%ecx/g' \
   | sed 's/%rdxd/%edx/g' \
   | sed 's/%rsid/%esi/g' \
   | sed 's/%rdid/%edi/g' \
   | sed 's/%rbpd/%ebp/g'

where qhasm-as and qhasm-fp are each awk scripts (222 and 427 lines, respectively).

source: http://cr.yp.to/qhasm/qhasm-20061116.tar.gz qhasm-20061116/qhasm-amd64

i'd argue that it's much easier to write bad Bash than bad Python

Assuming that "bad" doesn't mean merely "ugly to glace at." I find that depends largely on the problem at hand.