Martin Wilck <mwilck@suse.com> wrote:
Hi Jan, all,
I'd like to carry our OBS dicussion to a wider audience (https://build.opensuse.org/request/show/672510).
The question is whether we can assume that "/bin/sh" links to bash, in particular whether rpm scriptlets without explicit -p interpreter can be assumed to interpreted by bash.
I'm aware that, in principle, /bin/sh is supposed to be the Bourne shell on Unix systems. But as a matter of fact, on current openSUSE, it
UNIX used to have the Bourne Shell installed as /bin/sh, but I suspect that the Bourne Shell is not available on SuSe - or did you start to support "obosh" binaries recently? POSIX requires a platform to explicitly explain how to start a POSIX compliant environment. If this is not available the following method is described.... This typically happens if you call: PATH=`getconf PATH` sh since it is assumed that there is a special PATH with (by default) 100% POSIX compliant binaries (e.g. /usr/xpg4/bin or today /usr/xpg7/bin) and "getconf PATH" returns something like: /usr/xpg4/bin:/usr/ccs/bin:/usr/bin
is not. Unless it's tampered with, /bin/sh is a symlink to /bin/bash. bash is not started in full POSIX mode if invoked as /bin/sh, and even if it's in POSIX mode, it supports some extensions over the POSIX shell spec (e.g. the [[ ]] construct), which makes it behave differently than another shell not supporting [[ ]] would (*). Problably there are more differences, I can't claim to know them all.
Correct, [[ ... ]] is intentionally not part of the POSIX standard.
If we can't assume that /bin/sh is bash, what else can we assume? I recall from earlier work that writing really 100% compatible shell code for all kinds of environments is really hard. E.g., "[" isn't 100% portable either, even though it's part of the POSIX "test" standard (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html).
This is not correct, "test" is 100% portable if your scripts follow the POSIX rules. Note that you need to use only simple expressions as POSIX defines the behavior for up to 4 argument to "test" only.
We should have clear rules which syntax expressions can be used in rpm scriptlets, and which can't. IMO we should define one of the various existing shells as a reference by saying "if it's supported by this shell, it's valid scriptlet code". That'd be easier (especially for testing compliance) than referring to a spec. That reference shell doesn't have to be bash, of course.
Thanks Martin
(*) For example:
# ln -s /usr/bin/echo '/usr/bin/[[' # ls -l /bin/sh lrwxrwxrwx 1 root root 4 Feb 8 10:38 /bin/sh -> bash # /bin/sh --posix -c '[[ 2 = 1 ]] && echo yes'
This is definitely not portable at all, as --posix is not in the POSIX standard. This is the reason, why it is better to implement 100% POSIX compliant binaries in a special install path, as not even "-o posix" is defined by the POSIX standard.
# dash -c '[[ 2 = 1 ]] && echo yes' 2 -eq 1 ]] yes
dash prints: dash: 1: [[: not found Note that many Linux platforms today come with "dash" installed as /bin/sh but dash is not POSIX compliant as dash does not support multi-byte characters and POSIX only allows to omit the so called "XSI" support when on small embedded platforms. If you like to use something that is POSIX compliant and gives a similar set of features as dash, I recommend to use "pbosh", a minimal POSIX variant of the recent Bourne Shell development version. This shell has been verified to work perfectly on Gentoo Linux when installed as /bin/sh. Using "pbosh" makes sense since it is POSIX, supports multi-byte characters and is even a bit faster than dash. BTW: another problem with POSIX compliance related to bash is that bash by default implements a non POSIX "echo" builtin command. The bash binaries delivered with Apple and Solaris use a compile variant with POSIX compliant "echo". Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org