Categories
bash sh shell unix

Difference between sh and Bash

1688

When writing shell programs, we often use /bin/sh and /bin/bash. I usually use bash, but I don’t know what’s the difference between them.

What’s main difference between Bash and sh?

What do we need to be aware of when programming in Bash and sh?

3

  • 26

    For a useful list of bashisms and corresponding code that works on Bourne shell, see mywiki.wooledge.org/Bashism

    Apr 20, 2011 at 4:14

  • 1

    You may want to see the POSIX standard for sh and its command language: * sh * Shell Command Language

    Jul 23, 2013 at 3:01


  • 12

    as a general rule, all sh scripts will run under bash thanks to it’s posix compatibility, but not all bash scripts can run under sh, the main differences you notice are things like [[ ]] instead of [ ] comparisons which allow unquoted spaces, $(( )) instead of $[ ] arithmetic expressions, and other things like “its too big and too slow” directly from the bash docs.. But new scripters need not limit themselves to sh-compatible scripts unless they are shooting for some backward compatibility, which more often than not is not the case these days, after all it is (or was…) the year 2014 right??

    Mar 12, 2014 at 14:03

186

sh: http://man.cx/sh
Bash: http://man.cx/bash

TL;DR: Bash is a superset of sh with a more elegant syntax and more functionality. It is safe to use a Bash shebang line in almost all cases as it’s quite ubiquitous on modern platforms.

NB: in some environments, sh is Bash. Check sh --version.

3

148

This question has frequently been nominated as a canonical for people who try to use sh and are surprised that it’s not behaving the same as bash. Here’s a quick rundown of common misunderstandings and pitfalls.

First off, you should understand what to expect.

  • If you run your script with sh scriptname, or run it with scriptname and have #!/bin/sh in the shebang line, you should expect POSIX sh behavior.
  • If you run your script with bash scriptname, or run it with scriptname and have #!/bin/bash (or the local equivalent) in the shebang line, you should expect Bash behavior.

Having a correct shebang and running the script by typing just the script name (possibly with a relative or full path) is generally the preferred solution. In addition to a correct shebang, this requires the script file to have execute permission (chmod a+x scriptname).

So, how do they actually differ?

Bash aims to be backwards-compatible with the Bourne shell and POSIX, but has many additional features. The Bash Reference manual has a section which attempts to enumerate the differences but some common sources of confusion include

  • [[ is not available in sh (only [ which is more clunky and limited). See also Difference between single and double square brackets in Bash
  • sh does not have arrays.
  • Some Bash keywords like local, source, function, shopt, let, declare, and select are not portable to sh. (Some sh implementations support e.g. local.)
  • Bash has many C-style syntax extensions like the three-argument for((i=0;i<=3;i++)) loop, += increment assignment, etc. The $'string\nwith\tC\aescapes' feature is tentatively accepted for POSIX (meaning it works in Bash now, but will not yet be supported by sh on systems which only adhere to the current POSIX specification, and likely will not for some time to come).
  • Bash supports <<<'here strings'.
  • Bash has *.{png,jpg} and {0..12} brace expansion.
  • Bash has extended globbing facilities like ** (globstar) for recursing subdirectories, and extglob for using a different, more versatile wildcard syntax.
  • ~ refers to $HOME only in Bash (and more generally ~username to the home directory of username).This is in POSIX, but may be missing from some pre-POSIX /bin/sh implementations.
  • Bash has process substitution with <(cmd) and >(cmd).
  • Bash has Csh-style convenience redirection aliases like &| for 2>&1 | and &> for > ... 2>&1
  • Bash supports coprocesses with <> redirection.
  • Bash features a rich set of expanded non-standard parameter expansions such as ${substring:1:2}, ${variable/pattern/replacement}, case conversion, etc.
  • Bash has significantly extended facilities for shell arithmetic (though still no floating-point support). There is an obsolescent legacy $[expression] syntax which however should be replaced with POSIX arithmetic $((expression)) syntax. (Some legacy pre-POSIX sh implementations may not support that, though.)
  • Several built-in commands have options which are not portable, like type -a, printf -v, and the perennial echo -e.
  • Magic variables like $RANDOM, $SECONDS, $PIPESTATUS[@] and $FUNCNAME are Bash extensions.
  • Bash exposes some system facilities as file handles, like /dev/stdin, /dev/fd/<number>, /dev/tcp/<network address>, etc
  • Syntactic differences like export variable=value and [ "x" == "y" ] which are not portable (export variable should be separate from variable assignment, and portable string comparison in [ ... ] uses a single equals sign).
  • Many, many Bash-only extensions to enable or disable optional behavior and expose internal state of the shell.
  • Many, many convenience features for interactive use which however do not affect script behavior.

Remember, this is an abridged listing. Refer to the reference manual for the full scoop, and http://mywiki.wooledge.org/Bashism for many good workarounds; and/or try http://shellcheck.net/ which warns for many Bash-only features.

A common error is to have a #!/bin/bash shebang line, but then nevertheless using sh scriptname to actually run the script. This basically disables any Bash-only functionality, so you get syntax errors e.g. for trying to use arrays. (The shebang line is syntactically a comment, so it is simply ignored in this scenario.)

Unfortunately, Bash will not warn when you try to use these constructs when it is invoked as sh. It doesn’t completely disable all Bash-only functionality, either, so running Bash by invoking it as sh is not a good way to check if your script is properly portable to ash/dash/POSIX sh or variants like Heirloom sh.
If you want to check for strict POSIX compliance, try posh
in its designated POSIX mode
(which however does not seem to be properly documented).

As an aside, the POSIX standardization effort is intended to specify the behavior of various U*x-like platform behaviors, including the shell (sh).
However, this is an evolving document, and so, some implementations adhere to an earlier version of the POSIX specification; furthermore, there are some legacy implementations which didn’t even try to adhere to POSIX.
The original Bourne shell had some quirks which were later straightened out by the POSIX spec, which in large parts is based on ksh88. (Many of the Bash extensions are also innovations from ksh.)

4