分类：
2010-11-25 00:19:53
In Ubuntu 6.10, the default system shell, /bin/sh, was changed to dash (the Debian Almquist Shell); previously it had been bash (the GNU Bourne-Again Shell). The same change will affect users of Ubuntu 6.06 LTS upgrading directly to Ubuntu 8.04 LTS. This document explains this change and what you should do if you encounter problems.
The default login shell remains bash.
Why was this change made?
The major reason to switch the default shell was efficiency. bash is an excellent full-featured shell appropriate for interactive use; indeed, it is still the default login shell. However, it is rather large and slow to start up and operate by comparison with dash. A large number of shell instances are started as part of the Ubuntu boot process. Rather than change each of them individually to run explicitly under /bin/dash, a change which would require significant ongoing maintenance and which would be liable to regress if not paid close attention, the Ubuntu core development team felt that it was best simply to change the default shell. The boot speed improvements in Ubuntu 6.10 were often incorrectly attributed to , which is a fine platform for future development of the init system but in Ubuntu 6.10 was primarily running in System V compatibility mode with only small behavioural changes. These improvements were in fact largely due to the changed /bin/sh.
The Debian policy manual has long mandated that "shell scripts specifying '/bin/sh' as interpreter must only use POSIX features"; in fact, this requirement has been in place since well before the inception of the Ubuntu project. Furthermore, any shell scripts that expected to be portable to other Unix systems, such as the BSDs or Solaris, already honoured this requirement. Thus, we felt that the compatibility impact of this change would be minimal.
Of course, there have been a certain number of shell scripts written specifically for Linux systems, some of which incorrectly stated that they could run with /bin/sh when in fact they required /bin/bash, and these scripts will have broken due to this change. We regret this breakage, but feel that the proper way to address it is to make the small changes required to those scripts, discussed later in this document. In the longer term, this will promote a cleaner and more efficient system.
(This applies the same philosophy as in C and C++. Programs should be written to the standard, and if they use extensions they should declare them; that way it is clear what extensions are in use and they will at least fail with a much better error message if those extensions are not available.)
My production system has broken and I just want to get it back up!
If you are unlucky enough to have been negatively affected by this change, and only one or two shell scripts are affected, then the quickest way to fix this is to edit these scripts and change the first line to use the correct interpreter. The first line should look something like this (perhaps with some additional options): #! /bin/sh
Change that to the following (you can preserve any options you see): #! /bin/bash
In Makefiles, you can set the following variable at the top: SHELL = /bin/bash
If the problems are more widespread and you want to change the default system shell back, then you can instruct the package management system to stop installing dash as /bin/sh: sudo dpkg-reconfigure dash
Beware that this is a more invasive change, will undo boot speed benefits, and there is even an outside chance that there are a few scripts that now depend on some feature of dash that bash does not provide! (We expect the last problem to be rare, as the feature set of dash is largely a subset of that offered by bash, but we mention it for completeness.)
I am a developer. How can I avoid this problem in future?
We recommend that developers of shell scripts adhere to the , omitting those items flagged as XSI extensions. (This subset will be referred to as "POSIX shell" throughout the remainder of this document.) Doing so will improve portability to a variety of Unix systems, and will provide assurance that problems you encounter will be treated as bugs rather than as undocumented features! A special exception is that echo -n is guaranteed to be supported, although not other echo options (see below).
If you cannot use POSIX shell for some reason (perhaps you inherited maintenance of a large set of scripts and do not have time to rewrite them), then at least ensure that the first line of your script specifies /bin/bash as the interpreter.
Developers targetting the /bin/sh shipped by Solaris will have more stringent requirements, since that shell is a traditional Bourne shell predating the Korn shell and the POSIX standard: in particular, the test -e option is absent with no replacement (though most uses can be replaced with test -r), and test -h must be used rather than the test -L alias to test for symlinks. This document does not attempt to address Solaris in depth; consult your system's documentation.
There follows a list of some of the more common bash extensions (often referred to as "bashisms"). This list is not complete, but we believe that it covers most of the common extensions found in the wild. You can use dash -n to check that a script will run under dash without actually running it; this is not a perfect test (particularly not if eval is used), but is good enough for most purposes. The checkbashisms command in the devscripts package may also be helpful.
As further reading, install the autoconf-doc package and read the "Portable Shell" pages in info autoconf. This documentation is aimed at people targetting a wider variety of systems which may not support the POSIX standard, but it is nevertheless useful even to those assuming POSIX.
