It's really not. It's only present on some desktop Linux distributions. It's not present on almost any other OS or anywhere in the embedded space. POSIX shell, on the other hand, is everywhere.
I mean, what are the use cases? Where universality is important (so let's say when someone embeds scripts in Makefiles), I understand the need for POSIX, but other that I can't even come up with a good use case for having sh as default. (Maybe to save space, you ship the embedded device or Docker container with sh, sure, but then what kind of script you'd want to run there? Okay, maybe all of them, but then even on alpine installing bash is one quick command.)
Busybox is a thing. Many embedded devices don't have the luxury of installing Bash–you're stuck with what you've got.
I think you answered your own question here.
I can elaborate, though. bash isn't portable, it uses Glibc-isms. It has to be explicitly ported to new platforms. I also pointed out elsewhere that the value-add of bash is dubious at best - if you need to use bashisms you're better off not writing a shell script at all. So really, the question is: why do you need bash? You have to justify using non-standard tools, not the other way around.
And I feel the same with targeting POSIX sh.
Unless you have a really good business niche - like the aforementioned ftp script, use a proper language.
Yes, sysadmins were opposed to installing Bash. But if your core product depends on Bash and only on Bash, maybe I'd be opposed to everything about that deployment too.
And at the same time, I understand that there are IT tasks well suited to be solved with a script. But those don't seem to be the ones that require uber-portability.
If I need to setup something on a fleet of VMS-es, I'll use whatever I can get away with (including a lot of controlled substances to handle the dread of handling VMS), and won't think about what happens if we port this to HP-UX in the year 2525.
Indeed! The significance of this, I believe, is underappreciated.
During 2008-2015, when I used to work for a network security company, we had a file transfer script[1] for Unix and Linux systems. It was written entirely as a shell script. It began as a simple wrapper around the scp and sftp commands for which a shell script was appropriate. The fact that every Unix and Linux system comes with a shell meant that we could ship a single file to all target Unix and Linux systems without requiring the administrator to install any new packages. The alternative was writing the file transfer functionality in C or C++ which would have required us to build and test the solution for every possible Unix system that our customers used or writing it in Java which would have required us to require the customer to install JVM on their systems. Many customer admins were averse to installing any additional packages on their systems. Given these constraints, a shell script was a good solution.
Unfortunately, the initial shell script relied on several bashisms.[2] Some customers began complaining that their Solaris or AIX system did not have bash, and they needed the script to work with Bourne shell or Korn shell. The customers refused to install bash. So I decided to clean up the script, remove all bashisms from it, and ensure that only POSIX specified features were used, only POSIX specified commands were invoked with POSIX specified options only (with the exception of the scp and sftp commands of course because that was the primary reason why the customers wanted the script).
I am not fond of bashisms. If I need bashims like arrays or regex substitutions in parameter expansions, it's a sign that the script is becoming complex and I switch to a modern programming language. These days, when I write a shell script[3], I restrict myself to POSIX.2001 (2004 edition)[4], write unit tests to exercise every line of code, run the unit tests with bash, ksh, zsh, dash, posh, and yash on Debian, run the tests with bash, ksh, and zsh on macOS, and use Kcov[5] to measure test coverage.
[1]: https://community.rsa.com/docs/DOC-53124
[2]: https://mywiki.wooledge.org/Bashism
[3]: https://github.com/susam/vimer
You can test ksh93 and the MirOS Korn shell on Debian. For the Heirloom Bourne shell, though, look to FreeBSD, which has everything except the Watanabe shell.
* https://svnweb.freebsd.org/ports/head/shells/heirloom-sh/
* https://svnweb.freebsd.org/ports/head/shells/pdksh/
* https://svnweb.freebsd.org/ports/head/shells/ksh93/
* https://svnweb.freebsd.org/ports/head/shells/mksh/
* https://svnweb.freebsd.org/ports/head/shells/oksh/
* https://svnweb.freebsd.org/ports/head/shells/dash/
* https://www.freebsd.org/ports/shells.html
I appreciate what this sort of thing involves, as you can infer. (-: