When is #!/bin/bash
more appropriate than #!/bin/sh
in a shell script?
6 Answers
In short:
There are several shells which implement a superset of the POSIX sh specification. On different systems,
/bin/sh
might be a link to ash, bash, dash, ksh, zsh, &c. (It will always be sh-compatible though – never csh or fish.)As long as you stick to
sh
features only, you can (and probably even should) use#!/bin/sh
and the script should work fine, no matter which shell it is.If you start using bash-specific features (e.g. arrays), you should specifically request bash – because, even if
/bin/sh
already invokes bash on your system, it might not on everyone else's system, and your script will not run there. (The same of course applies to zsh and ksh.) You can use shellcheck to identify bashisms.Even if the script is for personal use only, you might notice that some OSes change
/bin/sh
during upgrades – e.g. on Debian it used to be bash, but later was replaced with very minimal dash. Scripts which used bashisms but had#!/bin/sh
suddenly broke.
However:
Even
#!/bin/bash
is not very correct. On different systems, bash might live in/usr/bin
or/usr/pkg/bin
or/usr/local/bin
.A more reliable option is
#!/usr/bin/env bash
, which uses $PATH. (Although theenv
tool itself isn't strictly guaranteed either,/usr/bin/env
still works on more systems than/bin/bash
does.)
-
10
-
3Just a remark if bash is run from
/bin/sh
then it will try to mimicsh
features (see man page), not sure bash specific features are available in this mode.env
tool is a posix tool it should be found in most distribution, but that I'm unsure as some may not respect posix.– bric3Oct 10, 2016 at 12:51 -
8No, in fact POSIX specifically states it can't be assumed to be in
/bin
: "Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in". Also see this question and, specifically this answer.– terdonOct 10, 2016 at 15:24 -
12Hmm, well, so that means POSIX doesn't actually define a portable way for having
#!
scripts work? Oct 10, 2016 at 15:30 -
4POSIX sh is not Bourne: it's more a derivative of early ksh than it is a direct descendant of Bourne. Distinguishing them is easy:
echo foo ^ cat
emitsfoo ^ cat
in POSIX sh, and emits onlyfoo
in Bourne (as^
is a pipe character there). Oct 10, 2016 at 20:15
Use the shebang corresponding to the shell you actually used to develop and debug your script. I.e. if your login shell is bash
, and you run your script as executable in your terminal, use #!/bin/bash
. Don't just assume that since you haven't used arrays (or whatever bash
feature you're aware of), you're safe to pick whatever shell you like. There are many subtle differences between shells (echo
, functions, loops, you name it) which cannot be discovered without proper testing.
Consider this: if you leave #!/bin/bash
and your users don't have it, they will see a clear error message, something like
Error: /bin/bash not found
Most users can fix this under one minute by installing the appropriate package. On the other hand, if you replace the shebang by #!/bin/sh
and test it on a system where /bin/sh
is a symlink to /bin/bash
, your users which don't have bash
will be in trouble. They'll most likely see a cryptic error message like:
Error in script.sh line 123: error parsing token xyz
This may take hours to fix, and there will be no clue about which shell they should have used.
There aren't many reasons why you'd want to use a different shell in the shebang. One reason is when the shell you have used is not widespread. Another one is to gain performance with sh
which is significantly faster on some systems, AND your script will be a performance bottleneck. In that case, test your script thoroughly with the target shell, then change the shebang.
-
@Hastur I don't get your comment. The shebang will certainly define which shell will be used to run the script, do you think my answer implies otherwise? Oct 12, 2016 at 9:14
-
1
Generally if time is more important than functionality you will use the faster shell. sh is often aliased to dash and tends to be used for root's cron tasks or batch operations where every (nano) second counts.
-
2Loading an extra shell interpreter from the filesystem can negate such an advantage, and anything where nanoseconds (which are in the same order of magnitude as an actual machine cycle) count is the domain of C and assembly language programmers. Oct 11, 2016 at 9:26
-
Nanoseconds only make a difference in cron jobs if you have billions of them, and cron won't be able to handle so many anyway. Oct 11, 2016 at 10:16
-
1Even if mckenzm exaggerated a bit, there's no denying that having more performance is better! Don't get hung up on the "nano" part. (Nanoseconds don't even count in C unless it's an inner loop on a real-time system or such!)– jpaughOct 11, 2016 at 21:30
-
1@jpaugh Unless you're working with a (legacy) system that assumes certain operations will take at least a specific period of time. It happens!– JABOct 12, 2016 at 18:12
You should only ever use #! /bin/sh
.
You should not use bash (or zsh, or fish, or ...) extensions in a shell script, ever.
You should only ever write shell scripts that work with any implementation of the shell language (including all the "utility" programs that go along with the shell itself). These days you can probably take POSIX.1-2001 (not -2008) as authoritative for what the shell and utilities are capable of, but be aware that you may one day be called upon to port your script to a legacy system (e.g. Solaris or AIX) whose shell and utilities were frozen circa 1992.
What, seriously?!
Yes, seriously.
Here's the thing: Shell is a terrible programming language. The only thing it has going for it is that /bin/sh
is the one and only script interpreter that every Unix installation is guaranteed to have.
Here's the other thing: some iteration of the core Perl 5 interpreter (/usr/bin/perl
) is more likely to be available on a randomly selected Unix installation than (/(usr|opt)(/(local|sfw|pkg)?)?/bin/bash
is. Other good scripting languages (Python, Ruby, node.js, etc. — I'll even include PHP and Tcl in that category when comparing to shell) are also roughly as available as bash and other extended shells.
Therefore, if you have the option of writing a bash script, you have the option of using a programming language that isn't terrible, instead.
Now, simple shell scripts, the kind that just run a few programs in a sequence from a cron job or something, there's nothing wrong with leaving them as shell scripts. But simple shell scripts don't need arrays or functions or [[
even. And you should only write complicated shell scripts when you don't have any other choice. Autoconf scripts, for instance, are properly still shell scripts. But those scripts have to run on every incarnation of /bin/sh
that's relevant to the program being configured. and that means they cannot use any extensions. You probably don't have to care about old proprietary Unixes these days, but you probably should care about current open-source BSDs, some of which don't install bash
by default, and embedded environments that give you only a minimal shell and busybox
.
In conclusion, the moment you find yourself wanting a feature that's not available in the portable shell language, that is a sign that the script has become too complicated to stay a shell script. Rewrite it in a better language instead.
-
4Sorry but that's a bit silly. Yes, if you're writing something that will be i) distributed and ii) to different environments, you should stick to basic
sh
. That, however, is a far cry from stating that you should never use other shells. There are thousands (probably many more) scripts written every day and the vast majority of those will only ever run on a single machine. Your advice makes sense on production code, but not for the daily "sysdaminy" jobs that most scripts are written for. If I know that my script will only ever be used by me and on a Linux machine, bash is fine.– terdonOct 15, 2016 at 11:11 -
1@terdon The point is that if you have the option of writing a bash script, then you also have the option of writing a perl (or whatever) script, and this is always the better choice.– zwolOct 15, 2016 at 16:33
-
@terdon The answer is surely not silly, your comment instead is simply naive. Shell scripts are terrible to debug compared to Perl and such, for which one can easily use complete IDEs with graphical debugging and all. Additionally, most of the scripts written every day for some small thing to do tend to be changed and changed all over again, grow, are copied as examples to colleagues or the net etc. There's most likely no reason to take such a risk. Oct 16, 2016 at 17:08
-
@ThorstenSchöning I said a little silly. If this were Unix & Linux or even Stack Overflow I might even agree. If we're talking about general best practice, or professional programmers, of course it's best to stick to basic POSIX sh. However, this is Super User, a site aimed at end users and telling people to never use bash or zsh when writing shell scripts is, in my opinion, extreme.– terdonOct 16, 2016 at 18:05
-
@terdon It is actually more important, in my opinion, to discourage end users from writing complex shell scripts. Professionals have a higher skill level on average (thus they are more likely to be able to cope with the pitfalls of complex shell scripting), should know with some precision which environments they need to be portable to, and are being paid not to give up in frustration.– zwolOct 16, 2016 at 18:10
To be even more brief, use sh
if portability across the most systems is most important and bash
if you'd like to use some of its specific features, such as arrays, if the version of bash supports it.
sh
(for most cases),bash
if specifically required (orksh
, or whatever)
The safest path. When hard coded, would be /usr/bin/<shellOfChoice>
but a new convention I am trying to use always now - as 'default locations' via a change PATH may change is:
#!/usr/bin/env sh
or
#!/usr/bin/env bash
or for e.g., perl scripts
#!/usr/bin/env perl -w
Of course, when you have a reason for a script to NEVER be automatically taking a new PATH then continue to have it hard-coded - and then /usr/bin/<something>
should be the most likely path to use.
bash
functions and syntax rather thansh
functions and syntax.vim
will highlightbash
-isms if your script has the#!/bin/sh
shebang. I only change it tobash
if things get hairy enough to start needing bash-features.$(...)
is particularly obnoxious. Also, some of them are subtle [<(...)
andcmd >& file
don't get any error highlighting, for example, they just don't have special highlighting for what they mean, with or withoutg:is_bash
]