If portability is your primary concern, then you want a POSIX shell, or at least to ensure that your bash is always in POSIX mode. There are lots of behavior differences when bash's POSIX mode is set.
Debian brought the Almquist shell in as /bin/sh, and is maintaining it with strict compliance to POSIX. This displaces bash as the system shell, but bash is still assigned as the interactive shell.
This is an older standard for the behavior of the POSIX shell. There are many common shell features that are not here (arrays, networking, coprocesses, fancy substitution, and much more). Doing without them increases portability.
In my view Debian boiled an ocean for no discernable gain and caused a lot of trouble for everyone in the process. Fedora is using bash and I hope we continue rejecting the mistake Debian made.
Bash does not "turn off" all its extra functionality when called as /bin/sh, it just alters the behaviors that are clearly in conflict with (what was) POSIX.2.
Arrays are still available in POSIX mode, even though they do not comply.
Except if any program calls system(3) which always using /bin/sh. I maintain many core Linux packages and this Debian nonsense is a constant irritation with no discernible benefit.
If it doesn’t work with ‘this Debian nonsense’, you’re doing it wrong and you’re contributing to a bad faux dependency on bash as /bin/sh.
The Unix world is better off if there is the option of using another shell that isn’t bug for bug compatible with bash.
This behavior is what leads to systems that have to emulate ancient bloated interfaces because they need to support applications that use apis that are defined as ‘how that program does it’. That’s bad. We should avoid it. Avoiding it is a benefit.
Android uses mksh. If I write a script that uses read -p to present a prompt, it will fail on Android because it means coprocess on mksh.
The fundamental reality is that GPL does not run on iOS or Android (in userland). If you want to run scripts on those platforms (and they are ENORMOUS), then you cannot use bashisms.
Are you building scripts for the Debian distro? Given that they already include bash and actually support it for interactive use, what would be the issue for you scripting using bash?
I am sure that the experience of moving to dash wasn't fun at all. But users in general are not affected that much as far as I understand.
I'm maintaining a bunch of core Linux packages which have had to make many adjustments over years for dealing with this Debian nonsense. I can see no justification for it since Fedora is using bash just fine and doesn't have to deal with this.
>There are lots of behavior differences when bash's POSIX mode is set.
AFAIU correct POSIX scripts will behave correctly with Bash POSIX mode. Incorrect POSIX scripts will not behave incorrectly with Bash POSIX mode as one might expect with a more faithful shell implementation.
IMO Bash POSIX mode is not a problem for running scripts, although you should test your scripts using a strictly shell implementation if you will then distribute those scripts to other users/platforms.
Debian brought the Almquist shell in as /bin/sh, and is maintaining it with strict compliance to POSIX. This displaces bash as the system shell, but bash is still assigned as the interactive shell.
http://gondor.apana.org.au/~herbert/dash/
This is an older standard for the behavior of the POSIX shell. There are many common shell features that are not here (arrays, networking, coprocesses, fancy substitution, and much more). Doing without them increases portability.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...