my personal belief is that anything one can do in bash i can do in sh. not sure if that's really true in practice, but that's my belief. i never use bashisms because i do not know what they are or how to use them.
In case you're not, here are some "Bashisms" that really suck to be without:
* built-in regex support (e.g. `[[ $var =~ ^1\.2\.[34]$ ]]`)
* process substitution (e.g. `diff <(before_command) <(after_command)`) and all sorts of other redirection tricks
* indexed and associative arrays
Some of this can be worked around by shelling off to grep for regular expression matching or awk for arrays, but Bash makes things so much cleaner and maintainable.
But once you adopt bash-only features, you're losing the main argument for a shell script: portable scripting without the need to first install something to get something else running. Once you require Bash, it's equally easy to demand Perl and that will provide a much richer scripting experience.
If you limit yourself to either a popular Linux distro or one of two Unixes/Unix-likes, then bash can be available out of the box. Just as C is not C++, shell is not bash, so a shell script is what runs on (d)ash, busybox, toybox, ksh, bash, zsh, etc., without modifications. If it requires bash or zsh, then it's not a shell script but a bash/zsh/fish script. To name a popular non-Linux OS, take a fresh FreeBSD or OpenBSD install. No bash to be found, unless installed via ports and rightfully so. That said, I use bash myself all the time as an interactive shell but /bin/sh is not bash. sh (including bash and zsh) are terribly hard to write correct and resilient scripts in, and even rc is much saner to script in.
> To name a popular non-Linux OS, take a fresh FreeBSD or OpenBSD install. No bash to be found, unless installed via ports and rightfully so.
And even if you do install it, it still won't work with scripts that specify /bin/bash (which is a lot of them, thanks to sloppy tutorials), since it will be in /usr/local/bin and not /bin.
I'm having trouble remembering the last time I saw a BSD box during my work day, unless Juniper gear counts. No knock against BSD but seriously how many people are writing POSIX shell scripts because they need their shell scripts to work with Linux, QNX and BSD?
A few, but there are still cases where it's best to stick with the plain old Bourne shell syntax.
When I mentioned embedded systems I primarily thought of Linux/Busybox-based devices, like OpenWRT. While one surely can have bash there, usually base image doesn't contain it.
Same story about the most common Linux-based OS out there: Android. And, while it's no one manually runs shell scripts there, apps quite frequently exec() things, so shell scripting still matters there - a tiny bit. Also, shell scripting is heavily used in firmware upgrades/patches, as well as a glue for the root/unlocking hacks.
If you plan to write a redistributable component or an useful hack for such platforms, you'd best stick with a very limited subset of POSIX.
In case you're not, here are some "Bashisms" that really suck to be without:
* built-in regex support (e.g. `[[ $var =~ ^1\.2\.[34]$ ]]`)
* process substitution (e.g. `diff <(before_command) <(after_command)`) and all sorts of other redirection tricks
* indexed and associative arrays
Some of this can be worked around by shelling off to grep for regular expression matching or awk for arrays, but Bash makes things so much cleaner and maintainable.