Mailinglist Archive: opensuse-factory (602 mails)

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

On 19/02/2019 04:16, Martin Wilck 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-

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. 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" (*).

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.


(#) that doesn't mean we actually have to test every shell code
snippet, but we _could_ in case of disagreement.
(*) ... and yields correct results for a reasonable set of possible

I think that as a starting point we might not even need to go this far.
A simple policy of "Contributors should accept submissions that remove
bashism's from scripts with a #!/bin/sh shebang or replace it with
#!/bin/bash" is reasonable. That way we are not blocking people who want
to work on this from working on it. Whether the shebang should be
replaced or the code is modified to be more compliant should be up to
the maintainer as they are the person who has to maintain the code long
term. At the same time submissions to factory shouldn't be blocked
because scripts in #!/bin/sh are using shell specific features.

Down the road if we decide as a project that we want to officially
support multiple shells as #!/bin/sh I'd like to see debians checkers
intergrated into rpmlint by the people who want to see this feature. I
also don't think we need to have and agree on one explicit reference
shell when I'm working on xdg-utils I generally go with use a subset of
functionality thats in both bash and dash, maybe in openSUSE's case
someone can make a compelling argument that pbosh should be added to the
list then thats a case for people who are actually working on making it
possible and wanting to run pbosh as #!/bin/sh to make. Not something we
should add because some people believe it is the closest thing to the
posix standard. We have to remember that the vast majority of the
scripts we are talking about here are openSUSE / SUSE specific install
scripts that wont make sense to run outside an openSUSE system and don't
really need to be portable to the unix's of a bygone era. If the scripts
don't fit that category then really they should be fixed wherever there
upstream is.



Simon Lees (Simotek)

Emergency Update Team
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups