A tale of two shells: bash or dash [LWN.net]

By Rebecca Sobol
July 29, 2009

A reoccurring topic on Debian lists is the use of dash (Debian Almquist Shell) as opposed to bash (GNU Bourne-Again Shell). Currently /bin/sh defaults to bash on a Debian system, but some would like the default to be dash.

Ubuntu made this switch three years ago, with the release of Ubuntu 6.10. Note that the default login shell remains bash, only the default /bin/sh used in shell scripts has been changed. Why did Ubuntu make this change?

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 Upstart, 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 EeePC project also notes that dash provides faster boot times. So why hasn't Debian already made this switch? In fact this was a release goal for Lenny.

Part of the problem is "bashisms" - use of non-standard bash features - in shell scripts. There is a lengthy list of bugs tagged with goal-dash that contain bashisms. These are being worked on, package by package. While some users report that they have already made the switch without problems, others will find many of their user scripts will have bashisms.

One can use checkbashisms (man page) to look for bashisms, but for users with lots of scripts using /bin/sh this could be a long and painful process.

Here's a sample of checkbashisms output for the package apertium:

checkbashisms' output:
> possible bashism in ./usr/bin/apertium-preprocess-corpus-lextor line 47
> ('((' should be '$(('): if ((length(w)>0) && (index(w,"^")>0)) {
> possible bashism in ./usr/bin/apertium line 9 ('function' is useless):
> function message

Examples of bashisms include use of $RANDOM, the select, let, and source keywords, shell arithmetic, the -e option to echo, and many other things.

Debian policy looks at SUSv3 Shell Command Language and states:

If a shell script requires non-SUSv3 features from the shell interpreter other than those listed above, the appropriate shell must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked "Essential" [policy 3.6], as in the case of bash).

You may wish to restrict your script to SUSv3 features plus the above set when possible so that it may use /bin/sh as its interpreter. If your script works with dash (originally called ash), it probably complies with the above requirements, but if you are in doubt, use /bin/bash.

This raises the issue of whether dash should be "essential" [see Debian policy section 3.8]. bash is "essential" meaning that it must be installed on every Debian system. If dash does not become "essential" then every script with /bin/sh as its interpreter must depend on dash to insure that it is installed and usable by /bin/sh (once the change is made).

That this change will be made is mostly not under debate, it is more a matter of when it will be fully implemented. Those that oppose the move simply want a choice, which exists using dpkg-reconfigure dash. Meanwhile users should be looking at their own scripts to see if they will break once /bin/sh defaults to dash.

(Log in to post comments)

Has anyone considered extending dash?

Posted Aug 6, 2009 14:07 UTC (Thu) by fbriere (subscriber, #4961) [Link]

Is anyone looking into what bashisms are "most popular" yet small, and perhaps should be implemented in dash as well?

Section 10.4 of Policy lists three such exceptions (namely, "echo -n", "test -a/-o" and "local"). They are not in the standard, but are deemed useful enough to be required of any shell claiming /bin/sh.

And, if they should, perhaps modifying the Single Unix Spec so that it includes those, too?

I wouldn't hold my breath on that one. :)

But it might be easier to use dash as /bin/sh if dash added a few of bash's conveniences.

Any script requiring bash features can always specify #!/bin/bash on its first line.

The issue with bashisms is not about people needing specific bash features, but about people not knowing that they are bash-specific. The bash(1) manpage doesn't state which features are standard and which are not, and the standard itself is not always easy to find (or read, for that matter). The dash(1) manpage can serve as a gentler approach, but even dash doesn't strive for strict standards complicance.

As a result, most script maintainers are blisfully ignorant of what the standard requires. (I myself strive to adhere to the standard, yet I didn't know until recently that "." searching the current directory is a bashism.)

So, unless dash implements all of bash (which would rather defeat the point), any transition is bound to hit a few bumps on that road.

Has anyone considered extending dash?

Posted Aug 7, 2009 18:43 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Any script requiring bash features can always specify #!/bin/bash on its first line.

And pay the price of Bash. The point is that it would be great if we could get the cheapness of Dash from many programs that were written for Bash.

The issue with bashisms is not about people needing specific bash features, but about people not knowing that they are bash-specific.

That's an important issue, but not the one that is the subject of this article. The instant issue with bashisms is that they exist today in scripts that specify #!/bin/sh, and that complicates making /bin/sh = Dash. Making Dash understand some bashisms can't completely solve the problem, but it could ameliorate it considerably.

The bash(1) manpage doesn't state which features are standard and which are not,

It also doesn't state which features are available in which versions of Bash, which makes it hard to write a #!/bin/bash program that works everywhere. And Perl and myriad programming libraries have the same issue. I'm expanding on this point to encourage people who write manuals for such things to consider including that information.

Has anyone considered extending dash?

Posted Aug 9, 2009 6:18 UTC (Sun) by jlokier (guest, #52227) [Link]

Not only that, but occasionally a new version of Bash will deliberately break something which worked in an older version of Bash. Just like Perl, really, but without the helpful warnings.

Has anyone considered extending dash?

Posted Aug 8, 2009 11:30 UTC (Sat) by marcH (subscriber, #57642) [Link]

> The bash(1) manpage doesn't state which features are standard and which are not,

I never use the Bash's man page. Bash's info manual has a "Features found only in Bash" section and is much better generally speaking. If, like many other people you dislike the basic info reader there are a number of alternatives like for instance "yelp info:bash"

> and the standard itself is not always easy to find (or read, for that matter).

Every time I have a doubt about standard conformance I just google for "opengroup + sh-keyword" and most of the time I just land automagically on a page that answers my doubt. In the worst cases the answer is only a few further clicks away.

Has anyone considered extending dash?

Posted Aug 13, 2009 17:23 UTC (Thu) by fbriere (subscriber, #4961) [Link]

> Bash's info manual has a "Features found only in Bash" section and is much better generally speaking.

Thanks, that's good to know. (Looking at it, I believe I might have erroneously used pushd/popd myself.)

However, it appears to be a list of generic features, so it's far from a thorough list. While the "Bash POSIX Mode" subsection goes into more detail, I didn't see any mention of, for example, bash-specific expansion patterns like ${foo/bar/baz}.

> Every time I have a doubt about standard conformance I just google for "opengroup + sh-keyword"

Unfortunately, bash (like Perl) has gobs of Google-unfriendly concepts. (Searching the standard for "." was fun...)

A tale of two shells: bash or dash

Posted Aug 6, 2009 10:00 UTC (Thu) by epa (subscriber, #39769) [Link]

Do you remember early Minix, when the standard /bin/sh shell was lean and fast, but with ash available as a more comfortable but bloated alternative for interactive use?

A tale of two shells: bash or dash

Posted Dec 10, 2009 16:51 UTC (Thu) by gvy (guest, #11981) [Link]

(waking up: which year it is, huh? :)

As already mentioned, having script-oriented shell for interactive use is a crime, and a silly one: one can have stripped-down $whatever (e.g. bash or dash) *without* readline support and half the other things as /bin/sh -- but enjoy proper zsh as an interactive chair.

Just in case, ALT Linux has sh and bash different since 2002.

Korn shell

Posted Aug 6, 2009 15:54 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

$ whatis ksh
ksh (1) - the Z shell

Korn shell

Posted Aug 7, 2009 10:36 UTC (Fri) by nix (subscriber, #2304) [Link]

Actually pdksh, used on Linux, has sufficiently many bugs not shared by other ksh implementations (many critical, some such actually documented as never to be fixed in the manpage!) that whenever I want a portable shell script of any complexity I write it in zsh. At least there's one implementation of that and bugs get fixed in it.

shell arithmetic is not a "bashism"

Posted Aug 7, 2009 20:34 UTC (Fri) by branden (subscriber, #7029) [Link]

It depends on which kind of shell arithmetic you're talking about.

The article's author may have been thinking of:

bash$ if (( 2 + 2 )); then echo yes; fi
yes

ash$ if (( 2 + 2 )); then echo yes; fi
ash: 2: not found

As the bash manpage notes, "This is exactly equivalent to let "expression"."

"let" isn't SUSv3, so (( )) isn't either.

You are probably thinking of:

$ echo $(( 2 + 2 ))
4

Which *is* SUSv3.

shell arithmetic is not a "bashism"

Posted Sep 4, 2009 10:32 UTC (Fri) by vapier (subscriber, #15768) [Link]

really you just backed up my point. while bash does have arithmetical extensions, the phrase used in the article is wrong. you cant lump "shell arithmetic" in with "let", "source", and "echo -e".