Python surpasses Perl in popularity?

Stephane CHAZELAS stephane_chazelas at yahoo.fr
Sat Nov 29 12:03:41 EST 2008


2008-11-29, 16:23(+00), Tam Ha:
> Jorgen Grahn <grahn+nntp at snipabacken.se> wrote: 
>>(I could get away with using Bash in these cases. It has functions, 
>>local variables and so on. Writing portable Bourne shell is not as 
>>much fun.)
>
> Can you explain this?  Bourne is always more portable than Bash.
> That's why you'll find experienced shell programmers writing everything
> that doesn't absolutely require a bash feature in /bin/sh.  Boot scripts,
> install scripts, etc. should never be written in bash and if where you
> find one using bash you can be sure a Linux-only newbie has written it.
> For one there are too many versions of bash, for two it is not installed
> by default on every Unix/Linux OS, for three it has poor backwards
> (and forwards) compatibility.  It is also found at different places on
> the path.
[...]

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. 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...

For a very long time, on a wide range of Unices, it has been the
Bourne shell (modified slightly in different ways by the
different Unix vendors), so that's probably why it is still
nowadays confused with the Bourne shell even though it is still
so only on very few Unices (mainly only Solaris, Tru64 and some
SCO OSes).

Nowadays, what the POSIX and Unix standards say is that a conformant Unix
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.

Shells that do implement an interpreter for that language
(though most shells of course have extensions which the
specification doesn't prohibit, such as many C compilers (like
gcc) have extensions to the standard C language as published by
the ISO) include (with lesser or greater accuracy) bash (2 or
above), the AT&T Korn shell (88<x> or 93<x> versions) and its
variants, the public domain Korn shell and its derivatives such
as posh, mksh or OpenBSD sh, modern variants of the Almquist
shell such as the NetBSD sh or dash.

That shell language is based on a subset of the ksh88 language
and the Bourne shell is not a conformant implementation. Amongst
the feature of the POSIX/Unix sh that are not in the Bourne
shell are the $(...) form of command substitution, arithmetic
expansions as in $((...)), the processing of IFS that differs,
redirections of compound commands that no longer invoke a
subshell... That language is mostly backward compatible with the
Bourne syntax though there are a few small differences.

To sum up, /bin/sh is no longer the Bourne shell. It is only so
on very old systems and on systems that have chosen to keep the
Bourne shell as /bin/sh for backward compatibility (and for
those, the standard sh is in another place such as
/usr/xpg4/bin on Solaris). Free software Unices have never had
the Bourne shell as their /bin/sh as the source code of the
Bourne shell has not been released until recently (except for
some early versions of BSD and they were then breaching the
law).

-- 
Stéphane



More information about the Python-list mailing list