Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Can we assume that /bin/sh is bash?
Mischa Salle <mischa.salle@xxxxxxxxx> wrote:

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.

A script that does not use non-POSIX features and that does not depend on
unspecified behavior (another important issue) is called "fully compliant".

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.

That's a joke, dash and ash are not POSIX because they do not support
multi-byte characters, which is required unless you are on a tiny embedded
system. ash was so buggy that people created dash from ash by fixing bugs.
The general idea on why Debian switched to dash seems to be useful.

zsh is so far from POSIX that it is not even able to run "configure" in it's
default behavior. When switched into it's POSIX mode, it still has noticeable
deviations from POSIX. Given that it is as slow as bash, I see nothing that
could cause an interest to install zsh as default shell.

ksh88 on the other side was the blueprint for the definitions that define the
"POSIX shell".

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

You finally need to test....

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.

So I recommend to try out other shells and to check the current scripts for
kshisms and bashisms. It may of course help to firsh use something like
"checkbashisms" on scripts that have #!/bin/sh inside or that do not have #!
at all.

This has been done with Gentoo Linux 2 years ago with pbosh and this helped to
identify and fix things that have been related to non-POSIX behavior in pbosh
as a result that this shell is a descendent from the original Bourne Shell and
the fact that not all differences between Bourne Shell and POSIX shell had been
documented before. So my advise is: do it and check whether you have system
scripts that depend on non standard behavior. You may have luck and there is
few to change.

BTW: In 2008, OpenSolaris has been converted to have ksh93 as /bin/sh and
several scripts have been changed. I needed to introduce minor changes (mainly
to avoid [[ ]]) into three system scripts in order to be able to install pbosh
as /bin/sh.

Given that this discussion is more than a simple question that ends after
someone posted an answer, you should run such a test and fix scripts that
include #!/bin/sh but depend on non standard- or on undefined behavior.


EMail:joerg@xxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog:
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups