Actually, there are still some bashism, and real foot traps at that. `trap EXIT` basically only "works" for try/finally behavior in bash, not even zsh. There should really be a warning around this in the article: if you want to be have portable cleanup for all exit conditions that works in different shells, you need a lot of busywork.

Where do you see such usage in the article?

why the bash hate? I thought it was really uncommon for any unixlike os to come without bash (sh symlinked to bash)

Linux in practice always comes with bash, but sh is not necessarily an alias; e.g. on the world's most popular distro:

    > readlink -f /bin/sh
    /usr/bin/dash

Also, BSDs and derivatives either have no bash installed by default (e.g. OpenBSD) or, in the case of macOS a horribly outdated one.

Finally there are good reasons to hate bash: Bourne shell is flawed but brilliant, whereas bash is a bloated mess of unpredictable and counter-intuitive behaviour that also tends to change between versions. It's also much, much slower than e.g. dash. Unfortunately even for pure shell scripting bash in practice is the way to go; posix shell (and dash) unfortunately lack a few things that are pretty crucial and very cumbersome to work around, like process substitution.

    > or, in the case of macOS a horribly outdated one.

The latest version of macOS defaults to zsh instead of the outdated version of bash.

Doesn't matter when shebang is #!/bin/bash

That's just for the login shell. It still ships with /bin/bash, and /bin/sh still by default invokes bash (in sh compatibility mode). However there is a systemwide flag you can set to make /bin/sh run dash or zsh instead.

That's mostly irrelevant, since basically no one writes shell code in zsh and this is unlikely to change that.

That's probably going to change with macs having it as the default.

Never underestimate the power of "Well, it worked on my machine"

People seem to be willing to do apt-gets (or equivalent) in docker files, I could see several of my old co-workers doing that just to get a script working.

Unlikely. Apple have made the default interactive shell zsh, but /bin/bash still stays around and I believe /bin/sh still aliases to it by default. Meanwhile there is an enormous ecosystems of shell scripts including countless curl ... | bash installers which no one has any motivation to port to some shell which is not installed by default on most Linux distros. Although Microsoft would undoubtedly be delighted with Apple accelerating the move of developers to Windows as the Unix of choice, I'm not convinced even Apple's current management is going to be dumb enough to remove bash altogether.

Why speak of hate?

The main problem I have with bashisms is that most people who use them just assume everyone runs bash as default shell. Instead of specifying xxx/bin/bash in their script, they use xxx/bin/sh (and they don't run any check about which kind of shell is running to ensure that bash is running and fail gracefully otherwise, and they don't either document that the script must be run from bash).

There's no problem about writing in a specific language, if you clearly say you did. If I stretch the example a bit, I wouldn't like a Python script to start with xxx/bin/ruby.

There is absolutely no Bash hate here.

If you do an experiment you'll easily find that dash is faster than bash, and since dash basically just a bare POSIX shell with very few extensions, a script that runs in dash is more likely to run anywhere (ignoring the fact that nearly every program you call from a shell script comes in both a GNU and BSD variant, and possibly a more minimalist POSIX version).

So I write my shell scripts to dash, which is /bin/sh on my system (Debian).

If you use Bash-isms, you should definitely not put #!/bin/sh at the top of your script, you should be putting #!/bin/bash

Just because it is present, doesn't mean its the default or used internally by things that call shell scripts.

For example... Not that long ago I started a new job where I took over as maintainer of a project with a fairly extensive Makefile, including targets for release. I cleaned it up some but missed a couple bashisms. The original author wrote it on a Mac, on which /bin/sh is bash, and used bashisms. I took over on Linux, which has /bin/sh as dash (POSIX). So while the author used it fine, it broke for me in subtle ways that I didn't notice until I made my first, broken release (error was in formatting of md5 signature file).

The problem with bashisms is that people don't think through if their current use case is an appropriate one.

just change the shebang

It's not bash hate. It's that a lot of the time, you don't have bash available (e.g., BusyBox environments), and you want your scripts to still work.

The `/bin/bash` on macOS is severely out of date. So a script that starts with `#!/bin/bash` will be unable to use a lot of features.

If you only rely on `/bin/sh` the user has the flexibility to point `/bin/sh` to whatever shell on their system is fastest and most up-to-date (e.g. `/bin/dash` is a pretty good choice for performance).

None of my FreeBSD machines have bash installed because it's not part of FreeBSD.

I don't know if it still is, but for a decent while, Debian sh was not bash.

Debian uses dash for non-interactive shell, but bash for the interactive shell (if I recall).

Indeed /bin/sh is still dash, not bash.

If someone asked you to list all the UNIX-like OS you know about, would BSD or Plan9 make the list.

As you should. Bash --- at least bash 3.x --- is available literally everywhere and has many features essential for robust programming, like local variables. Instead of writing for some antique shell, we should all just write for bash or zsh or something modern. I don't care about being compatible with some random AIX installation that's from 1870 and powered by a steam engine.

sh is used because it is POSIX sh–you know it will work not "literally everywhere" but really, truly, literally everywhere. And your bashisms aren't going to do all that well on BusyBox, or dash. Just because you don't care doesn't mean that we should make incompatible scripts and not be aware that we are doing so.

One counterexample: bash isn’t available in the base system of typical BSD variants (though, yes, you can install it from ports).

I've worked on storage-constrained embedded systems where adding bash and its dependencies expanded my root filesystem by 50%. busybox ash is a much smaller alternative.

Security teams love stripping bash out of linux images. I was forced into living a pure sh diet while working for a bank.

If I want to use modern features, I’ll just use Perl or Python, both of which are also available literally everywhere.

Or I'll just write it in Go and easily cross compile an execuable binary for whatever platform I need.

It is however useful to know the difference, and in some cases you actually need to write POSIX (code meant to be sourced for example).

As others have mentioned... not everywhere. And sometimes you’re just writing something that really shouldn’t require a dependency on bash.

You wouldn’t write a Python script to run a few quick shell commands like copying a few files around. Same concept.

This would make sense if it said "zsh" instead. Not only is only better in terms of features, it's also released under a non-problematic Open Source license.