Hi,
On Mon, Feb 18, 2019 at 6:46 PM Martin Wilck
On Mon, 2019-02-18 at 13:36 +0100, Joerg Schilling wrote:
Mischa Salle
wrote: I might have missed part of this (very long) discussion, but in my opinion - 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 any 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- compliant. 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 /bin/sh). 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 https://lists.opensuse.org/opensuse-packaging/2010-03/msg00076.html
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 openSUSE.
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.
Best, Mischa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org