[chasil]

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.

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...

[rwmj]

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.

[stouset]

If you want to write scripts to target bash, target bash with your shebang.

If your shebang is `/bin/sh`, then it's nice to have a strictly POSIX-compliant shell.

[chasil]

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.

[stouset]

Which is why I think it’s good that Debian has a POSIX-strict `/bin/sh`. I have no idea what bash’s flawed POSIX mode has to do with this.

[rwmj]

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.

[tinus_hn]

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.

[chasil]

One secondary reason for the dash choice is speed.

The dash shell has been reported to be four times faster than bash.

That definitely impacts boot time. POSIX compliance is not the only benefit.

[hnfong]

system("/usr/bin/env bash -c '...'");

[chasil]

Debian dash is useful to keep my scripts honest.

Busybox actually takes dash, and then sprinkles a few bash/korn features back onto it (notibly, not arrays).

If you want a lot of people to use your scripts, getting them working in dash can help a great deal.

The POSIX mode in bash exists because bash itself predates POSIX by nearly a decade.

[rwmj]

What does "keep my scripts honest" even mean? Just use bash and don't make everyone else boil your ocean.

It's like saying you'll never use any Linux feature except those strictly defined by POSIX.1. Why would you do that?

[chasil]

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.

Full stop.

[kazinator]

Note: BusyBox has two shell implementations in it, selected at compile time.

[malkarouri]

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.

[rwmj]

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.

[chasil]

I definitely feel great sympathy for your position.

[Ferret7446]

>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.