Python surpasses Perl in popularity?

Stephane CHAZELAS stephane_chazelas at
Sun Nov 30 10:46:27 CET 2008

2008-11-30, 06:11(+00), Tam Ha:
> Stephane CHAZELAS wrote:
>> There's a common confusion in this in the nature of /bin/sh.
>> There's no standard (neither POSIX nor Unix) that specifies that
>> /bin/sh should be any variant of the Bourne shell.
> Sure there is, POSIX.  Or rather their Austin Group. And while they done
> an extremely poor job of it the POSIX shell is still the Bourne shell,
> /bin/sh as it's always been known, with a few enhancements such as tilde
> expansion and such.

No, saying that /bin/sh is the Bourne shell is as wrong as
saying /bin/csh the Thomson shell. It's at best a very
inaccurate approximation but it's true it's a very commonly made
mistake. All you can say is that "sh" is meant to be a POSIX
compliant shell (which the Bourne shell is not) or that /bin/sh
(nowadays) is a Bourne-like shell. If you want to write a shell
script for the /bin/sh of any modern Unix, you have to write it
in the language that is the intersection of that of the Bourne
shell and the POSIX shell syntax.

As I said, the POSIX shell specification is based on a subset of
ksh88, has incompatibilities with the Bourne shell. The Bourne
shell, as can still be found on some systems either in some
non-standard place (/bin on Solaris, /usr/old/bin on HPUX) or
named differently (see for more details)
is not conforming to that standard.

On most commercial Unices, the "sh" utility is implemented by
one version of the other of ksh88 (possibly slightly modified).
That's the case at least of Solaris (where it is in
/usr/xpg4/bin/sh, and you can see that /usr/xpg4/bin is before
/bin in the output of "getconf PATH"), HPUX since at least
10.10, AIX since at least 4.3.2, IRIX...

See on Tru64

sh(1)> [Tru64  UNIX]  Subsequent  shells spawned from the initial
sh(1)> shell depend on the  value  in  the  environment  variable
sh(1)> BIN_SH.   If this variable is set to xpg4, the POSIX shell
sh(1)> is started. If this variable is set to svr4, an SVR4
sh(1)> compliant version  of the shell is started. If this
sh(1)> variable is unset, the Bourne shell is started. If this
sh(1)> variable is set  to  any  other  value,  an  error is
sh(1)> reported and the results are unpredictable. See the
sh(1)> EXAMPLES  section  for information on setting this
sh(1)> variable.

The POSIX one being ksh. On Linux and all the GNU OSes, it's
generally bash. On BSDs, it initially was the Almquist shell, a
public domain rewriting of the System V shell (the Bourne shell)
with a few modifications, and nowadays FreeBSD and NetBSD have
adapted that ash so as to become POSIX compliant, and OpenBSD is
using pdksh. MacOS/X has been using zsh and now bash

>> Over the years and on the different flavours of Unix, /bin/sh
>> has been a Thomson shell, Mashey shell, Bourne shell and all its
>> variants, Almquist shell, bash, ksh, zsh...
> Zsh? Seriously? Where?

Some versions of MacOSX/Darwin.

> used various poorly designed "compatiblity mode" hacks to circumvent
> Bourne/POSIX regardless of compatibility consequences does not change
> the fact that /bin/sh is still there in all distributions, is still the
> cross-platform compatibility winner by a county mile, and can still be
> relied on for shell scripts.

Could you please clarify what you mean? Yes, most systems have a
/bin/sh (for those that have a /bin directory), but as I said
/bin/sh can be any of a Thomson, Mashey (only in museums
nowadays), Almquist, Bourne, Korn, bash...

Nowadays, they are most likely to be Bourne-like.

If you want to write a portable script, today, the best advice
to give is to write it in a syntax conforming to POSIX (note
that of course that applies to the shell but also to the
standard utilities). Then you'll be guaranteed to find a "sh" on
any compliant Unix (most at least try to be nowadays) that will
interpret it. It is a much better situations than a few decades
ago where every vendor had its own variant of the Bourne shell
and the utilities.

>>should have somewhere (and the location is not specified but on
>>most Unices except those quoted above is generally /bin) a
>>command called "sh" that is an interpreter of the POSIX shell
>>language it defines.
> Right, that's /bin/sh. 

Not always. As I said, on a few systems, the POSIX sh is not in
/bin. That's the case of at least Solaris, where /bin/sh is a
Bourne shell and therefore not a POSIX compliant sh.

> It's common name is the Bourne shell even though
> it is not the code that Mr Bourne wrote years ago, and even though
> GNU/POSIX and ATT/David Korn want to remake it into a "POSIX shell"
> regardless of the compatibility consequences.

Saying that would be denying the reality.

>>That shell language is based on a subset of the ksh88 language
>>and the Bourne shell is not a conformant implementation. 
> Only if you limit your use of the term "Bourne shell" to something
> that the rest of us don't recognize as a Bourne shell.  The fact that
> POSIX has been known to jerry-rig ksh features (most of which werre
> derived from tcsh by the way) into /bin/sh (and sort, and a few other
> APIs they really should not be changing) only reflects the fact that
> A) David Korn (still with ATT) has been pushing his vision, and B)
> systems administrators (the ones who suffer most from cross-platform
> incompatibilities) are not well represented within POSIX in general,
> and not well represented within its Austin Group in particular.

A few tcsh features have made it to bash and even more to zsh
but mostly only on the interactive usage side not the syntax
but hardly any to ksh, ksh has added a few features from csh
such as tilde expansion, brace expansion (though differently),

The reality is that nowadays the Bourne shell has almost
disappeared, but it's syntax is still used in scripts, which is
most cases, modern shs can still interpret.

I would strongly recommend the reading of and which is a very
good reference on sh and the Bourne shell.


More information about the Python-list mailing list