Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Can we assume that /bin/sh is bash?

On Mon, Feb 18, 2019 at 6:46 PM Martin Wilck <mwilck@xxxxxxxx> wrote:
On Mon, 2019-02-18 at 13:36 +0100, Joerg Schilling wrote:
Mischa Salle <mischa.salle@xxxxxxxxx> wrote:

I might have missed part of this (very long) discussion, but in my
- using /bin/sh means you SHOULD only use constructions which are
POSIX compliant.
- when you want to use bashisms, use /bin/bash. The same applies to
other shells.

This is finally the right conclusion even thouh POSIX does not make
statements on what /bin/sh is.

I don't think that this is the right conclusion. Here's why.

I've been told in this discussion that the POSIX shell standard for
"allows extensions". IOW, it only defines a minimal set of features,
and implementations are free to add more features on top and still
"comply" with the standard. Therefore the fact that bash, invoked as
"/bin/sh", supports the non-POSIX '[[ ]]' syntax doesn't make it non-
Correct, *but* I'm saying the opposite: if you stick to the POSIX set
of features, your script should be portable, which is not the case if
you use extensions.

We need to define without ambiguity under what conditions a _shell
script_ complies with the feature set of "/bin/sh". That means that we
need to have a _test procedure_ (#). We could say that "code is
compliant iff it runs without errors under every POSIX-compliant shell
(*)". But that's hard to test, as we'd have to test with every POSIX-
compliant shell out there, and we may not even know them all.
This is indeed a hard(er) question. I'd say checkbashisms (part of
Leap's main repo) would be a good start. That's also what Debian is
doing in lintian AFAIK (Debian by the way has dash as the default
In general dash and ash are considered more POSIX close that bash,
zsh, ksh etc. That doesn't mean you should per se use dash or ash as
your default shell, but you can use them as a step in checking for
POSIX compliance.

We also
don't want to test by human beings parsing the code (even if that's
basically what Jan is doing today). Rather, we need to settle on an
actual shell implementation, and define "compliant" by reference to
this implementation: "shell code is compliant iff it runs without
errors under this implementation" (*).
Indeed, which is why AFAIK Debian went for dash.
Note by the way that there is a long thread from about 9 years ago,
starting with

That implementation could be bash in POSIX mode, meaning that e.g.
'[[ ]]' would be allowed. Alternatively, it could be a minimal shell
like "pbosh".

So far the discussion in this thread did not come up with a prime
candidate for being that reference shell. dash has been propoposed and
then harshly dismissed. ash, likewise. I suppose that Jörg would
propose "pbosh", and it seems to come closer to the ideal of a "strict"
POSIX shell as anything else mentioned up to now. But I'd call it a bit
exotic. It doesn't seem to have a lot of real-world users under

I still fail to see the benefit of choosing anything else than bash in
POSIX mode for /bin/sh, unless we want to pursue the long-term goal to
be able to run (a minimal) openSUSE completely without bash.
The point is not what to choose as /bin/sh, but which constructs to
accept in shell scripts. It would be bad to use bashisms, zshisms or
any other isms in a /bin/sh, but that's about the code, not about the
underlying shell.
If we now start using bashisms in the shell scripts, because currently
/bin/sh is /bin/bash it will make it much harder to ever change bash
for another shell, while if you stick to POSIX construct only, it's a
single change.

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups