In most shell scripts I've seen (besides ones I haven't written myself), I noticed that the shebang is set to #!/bin/sh. This doesn't really surprise me on older scripts, but it's there on fairly new scripts, too.
Is there any reason for preferring /bin/sh over /bin/bash, since bash is pretty much ubiquitous, and often default, on many Linux and BSD machines going back well over a decade?
/bin.
/bin/sh is faster if it's not bash, there still are a few systems like OS/X or RHEL where /bin/sh is bash.
– Stéphane Chazelas
Dec 22 '15 at 15:36
ksh93, followed by the Schily Bourne Shell and directly followed by dash. dash is however only fast because there is no multi-byte character support in dash.
– schily
Dec 22 '15 at 16:45
system(), popen() or other one-line simple commands and short and simple scripts. pdksh and derivatives can also beat dash or ksh93 on some things.
– Stéphane Chazelas
Dec 22 '15 at 17:12
/bin/sh is /bin/bash. Ubuntu switching from bash to dash broke all of them.
– atamanroman
Dec 22 '15 at 18:58
#!/bin/bash if they wanted Bash (nothing wrong with that!). The change was mostly done upstream in Debian. It improved user experience, it had a measurable impact on system startup time. It also positively impacted security, see "Shellshock".
– Dietrich Epp
Dec 22 '15 at 23:28
time $shell -c '' seems to me like a good way of measuring the time a shell takes to start and to exit.
– Blacklight Shining
Dec 23 '15 at 08:52
shell -c ':') and even on a 10 year old machine, I get something around 2ms per Bourne Shell call (dash is a bit faster) and 4ms for ksh93, but yash is even slower than ksh93 and times in that magnitude are not a problem - in special as /bin/echo (6kB) needs 1.5ms.
– schily
Dec 23 '15 at 09:55
#!/bin/sh. "Simple scripts" may not require bash, as he says in point 3, but if you didn't test your script with anything but bash, you shouldn't be using #!/bin/sh.
– Wildcard
Dec 24 '15 at 09:34
Most system scripts in (Debian related: Ubuntu, Mint, etc.) Linux are written to run in the faster dash, which is the default /bin/sh in those systems. The reason is twofold:
Speed of the system. A smaller code of dash loads faster and also run faster. With some (small?) additional effort (cost) to programmers of shell scripts.
Security. Having diversity of shells helps resilience to bugs. Debian systems were mostly not vulnerable to shellshock because the default shell did not have such vulnerability.
Bash is indeed the default shell for users, as is more powerful and has much more elements to make coding easier. It is also the default sh in Mac OS (the one linked from /bin/sh). However, calling bash with the link name of sh makes it start as a posix compliant shell.
eval, with attendant security exposure; similarly, without built-in regex support, one can need to use external commands (at a heavy performance penalty) for matching even within a single line, etc.
– Charles Duffy
Dec 22 '15 at 18:30
Others have pointed out that the premises of the question, that the Bourne Again shell is default and ubiquitous, are downright wrong.
In addition to that, there are indeed good reasons for using something other than the Bourne Again shell for interpreting shell scripts. These reasons motivated Ubuntu's and Debian's big project, over a number of years, to remove bashisms and to make as many of the shell scripts run by system initialization (which was a lot of shell scripts with System 5 rc) and package installation/removal use the Debian Almquist shell instead of the Bourne Again shell.
Simply put: The Bourne Again shell, chock full of interactive features as it is, is not the fastest shell interpreter for a POSIX-conformant shell script. So if one can make one's shell scripts POSIX-conformant, interpreting them with a more lightweight program, like the Debian Almquist shell, one's system will perform better. (In the end, Debian had to make slight adjustments to the Almquist shell, to add support for a couple of non-POSIX shell constructs that were simply too deeply and widely embedded and too useful to get rid of.)
The result of it all was a major gain in bootstrap performance.
So there are two distinct classes of shell to consider, here:
Note that talking about this as "preferring /bin/sh" is oversimplifying. Debian actually had at least two goals:
In the face of administrators using the Debian Almquist shell, the Z Shell (in POSIX mode), the Bourne Again shell (in POSIX mode), the MirBSD Korn shell, and others as /bin/sh, there was either …
… making the scripts as portable as possible, so that switching what /bin/sh mapped to didn't break things; or
… making non-portable scripts explicitly target the correct interpreter program, instead of simply expecting that /bin/sh map to it.
There was making the Debian Almquist shell the default mapping for /bin/sh instead of the Bourne Shell, so that those scripts that were POSIX-conformant (or, more properly, Debian Policy Manual conformant) ran more quickly.
And of course once one gets into this, one can take it a lot further; such as considering the efficiency tradeoffs of the likes of /bin/true and /usr/bin/clear being shell scripts or compiled programs. But that's beyond the scope of this answer, fortunately. ☺
None of this is very new, nor even Unix-specific, of course. Back before the turn of the century, I wrote and published a command-line interpreter that came in both "interactive" and "non-interactive" flavours, explaining this very division in its doco and noting the difference between the COMSPEC and OS2_SHELL environment variables. Similarly, discussion of removing bashisms in Debian's System V rc and package installation/removal scripts dates back to the 1990s.
/bin/sh. Ubuntu wiki./bin/sh. Debian wiki.
Schily Bourne Shell man page, see http://schilytools.sourceforge.net/bosh.html are suitable to permit people to understand how to write a portable script (that only depends on Bourne Shell features from 1989). What I did was mentioning every enhancement that was not in old Bourne Shells. BTW: I am also interested to know a list of bashisms in dash.
– schily
Dec 23 '15 at 09:59
Is there any reason to have a shebang pointing at /bin/sh rather than /bin/bash?
Yes. @Marco's excellent answer outlines this well.
What should I use in my shebang?
When writing your own scripts, you should point the shebang to the most general thing that you have tested against.
On my system (Centos 6.6), sh is symlinked to bash:
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Dec 2 2014 /bin/sh -> bash
This means that I always use #!/bin/bash in my shebang unless I have verified that I don't have bashims in my script.
By setting the shebang to #!/bin/sh you are promising that the script will work with all implementations of sh.
This is a much bigger promise than saying the script will work with bash.
Here is an example of a script that will behave incorrectly depending on what sh implementation the system is using:
#!/bin/sh
n=1
a=$((++n))
echo $n
When using bash the script will print:
2
When using dash the script will print:
1
If I want to use #!/bin/sh what do I need to do?
checkbashisms - Note that this will not find all bashims. It didn't find the bashism in my script abovesh implementation. I typically test with dash, however I expect that some bashisms or dashims can still slip through. The DashAsBinSh page on the Ubuntu wiki has lots of interesting info.
/bin/sh; just the POSIX-compliant ones.
– Blacklight Shining
Dec 23 '15 at 09:00
The only remaining reason to write a shell script, instead of a script in a more powerful and ergonomic language, is if portability to legacy systems with an unknown set of installed software is more important than any other factor.
/bin/sh is the one and only script interpreter that's available on everything that calls itself Unix. But on an awful lot of legacy systems, /bin/sh and the associated utilities are not even compliant with the POSIX.1-1996 "shell and utilities" spec, let alone anything more modern. Standard-compliant tools are an optional add-on, installed in /usr/xpg4 or some such non-obvious location.1 Scripting to the portable-subset shell language is even more tedious and error-prone than scripting to the POSIX shell language. (Read through an Autoconf-generated configure script sometime if you don't believe me. Just the setup should be enough to convince you.)
But if you can assume any other script interpreter is installed (e.g. Bash) then you can assume an interpreter for a better scripting language is installed. Perl, for instance, is more likely to be available than Bash is.
Therefore, you should never write a #! /bin/bash script, because if that's an option, a better language is also an option.
1 For instance, Solaris 10 and older shipped the original Bourne shell as /bin/sh. I am informed that Solaris 11 updated it to ksh93.
/bin/sh is not POSIX.1-1996 but actually a pre-POSIX syntax original Bourne shell. That makes #!/bin/sh a very poor shebang for scripts to run with these releases. Portable scripts on Solaris would use #!/usr/xpg4/bin/sh which won't be very portable on other OSes. On the latest Solaris, Oracle Solaris 11 first released 2011, /bin/sh is a modern ksh93 that complies with recent POSIX specs, and has many modern extensions.
– jlliagre
Dec 22 '15 at 16:53
ash which is provided with busybox), and I tend to think zwol is right that perl is more commonly available than bash.
– Ben Voigt
Dec 22 '15 at 16:53
#! /usr/xpg4/bin/sh, it has to use #! /bin/sh, so prior to Solaris 11, it would get the pre-standardization shell. Thanks for the information about exactly when this changed; I'll update the answer to be more precise
– zwol
Dec 22 '15 at 17:51
/usr/xpg4/bin/sh is a ksh88 on Solaris.
– schily
Dec 22 '15 at 18:03
/bin/sh. As the fisrt paragraph of the shell standards states As it stands, a strictly conforming application must not use "#!" as the first two characters of the file. In any case, that would be much better than using #!/bin/sh on Solaris. Also, a POSIX compliant script must be run from a POSIX compliant shell. The fact is if you want your scripts to be portable, you need to either adapt them at installation depending on the platform they are installed to, or to use other tricks to have them executed by the POSIX compliant shell.
– jlliagre
Dec 22 '15 at 18:31
ksh93 is indeed not strictly POSIX compliant, but neither is bash, even with the posix flag set. My point was ksh93, like bash, complies enough with most POSIX specs for the majority of scripts not using bashisms (or kshisms) to work without too much uncertainties. There will always be corner cases though...
– jlliagre
Dec 22 '15 at 18:40
#! /bin/sh is an adequate starting point, although you do indeed have to jump through a great many hoops to bootstrap yourself from that point. Again, see the first couple thousand lines of any Autoconf-generated configure script.)
– zwol
Dec 22 '15 at 18:51
bash, ksh, zsh or any specific shell but if your script doesn't use any specific constructions or syntax, a #!/bin/sh shebang might hurt more than fix things, at least on Solaris 10 and older.
– jlliagre
Dec 22 '15 at 19:06
PATH= the result from command -p getconf PATH. Then type sh.
– schily
Dec 22 '15 at 21:22
csh), although anything named /bin/sh should support the original bourne way.
– jlliagre
Dec 22 '15 at 22:27
bash is available then so is a better language so you should never write any bash code." Also, as @sixtyfootersdude points out, you should always use #!/bin/bash unless you have tested that your script works with any POSIX shell.
– Wildcard
Dec 23 '15 at 02:55
You should actually be using either
#! /bin/env sh
or
#! /bin/env bash
that way you invoke either shell by the way they're install on that system.
To be super safe (eg in cases of single-user reboots) use sh otherwise use bash.
The disadvantage of #!/usr/bin/env python is that it will use whatever python executable appears first in the user's $PATH.This probably also applies toshandbash`.
#!/bin/env anything in a portable script. It is perfectly reasonable to assume that /bin/sh exists and is a working, POSIX-compliant shell. On the other hand, none of my systems have a /bin/env.
– Blacklight Shining
Dec 23 '15 at 09:04
/bin/sh. POSIX does not require it and rather defines other rules to get a POSIX compliant environment on a POSIX certified platform.
– schily
Dec 23 '15 at 18:17
/bin/shif you do not use specificbashfunctions. One day you could have to use one of your script on a system on which it is not installed (remote server, embedded computer...) – Mathieu Dec 22 '15 at 13:52...the answers so far are fairly subjective...A "subjective" statement is essentially opinion-based by definition./bin/bashshould only be used when bash is explicitly needed. In 40+ years as a developer, long beforebash, I almost never explicitly needed it except when testing. (I also strive to avoid shell extensions, but most of my scripts are intended for distribution.) Many scripts on the net should also be intended for wide use. – user2338816 Dec 23 '15 at 05:18#!/bin/bash. – mikeserv Dec 23 '15 at 07:35#!/bin/shshould not be used if a script containsbashismsbut it is also good practice to try to write scripts in a way that would allow execution with theSVr4 Bourne Shell. Compatibility with theSVr4 Bourne Shellcan be checked using theoshbinary from the Schily Bourne Shell http://schilytools.sourceforge.net/bosh.html – schily Dec 23 '15 at 13:46