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@gmail.com> 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.
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 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.
Regards, Martin
(#) 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 inputs.
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. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek 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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org