Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] Can we assume that /bin/sh is bash?
Martin Wilck <mwilck@xxxxxxxx> wrote:

Hi Jan, all,

I'd like to carry our OBS dicussion to a wider audience

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`

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

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.


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

# dash -c '[[ 2 = 1 ]] && echo yes'
2 -eq 1 ]]

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


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