2008-11-29, 16:23(+00), Tam Ha: > Jorgen Grahn <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list