How to make bash scripts work in dash

This page is an attempt to list some of the most common bashisms, i.e. features not defined by POSIX (won't work in dash, or general /bin/sh). It probably won't be exhaustive. Note also we talk about "bashism" because this wiki is largely bash-centric but a number of these extensions work in other shells like ksh or zsh.

Syntax

Expansions

• Brace Expansion, eg {a,b,c} or {1..10} is not defined by POSIX. Both forms are present in ksh93, and the first form in older ksh.

• The <( ) and >( ) process substitutions are not defined by POSIX, but can be simulated with FIFOs: instead of foo <(bar), write mkfifo fifo; bar > fifo & foo fifo or bar &| foo <&p (this is basically how process substitution is implemented on OSes that don't have a mechanism like /dev/fd/ to refer to unnamed pipes with filenames). It is present in ksh93.

Parameter Expansions

List of expansions not defined by POSIX:

• ${name:n:l} -- if the variable contains no newlines, you can use $(printf '%s\n' "$name" | cut -c $n-$((n+l-1))). If there are newlines, you can use $(printf %s "$name" | dd bs=1 skip=$n count=$l 2>/dev/null), but printf may report a (harmless) broken pipe if the variable contents are large enough. This form is present in ksh93.

• ${name/ } -- you can use $(printf '%s\n' "$name" | sed 's/foo/bar/'), after changing shell patterns to regular expressions. This form is present in ksh93.

• ${!name} -- bash-specific; it is possible, but dangerous, to use eval to achieve similar effects; see BashFAQ/006.

Note that using $( ) has the side-effect of removing trailing newlines from the results. Furthermore, since many standard Posix utilities, such as sed, require text files as input, you should ensure their input ends in a newline.

Arrays

Arrays are not defined by POSIX (but are present in ksh); there is no easy general workaround for arrays. Here are some hints:

• The positional parameters are a kind of array (only one array):

#build a command dynamically see [[BashFAQ/050]]
set -- 'mycommand' 'needs some complex' 'args'
"$@"
#access the i'th param
set -- one two three
i=2
eval var=\$$i #take care if i comes from some user input see below
echo "$var"

• use IFS and set -f

• eval is powerful but dangerous so use it wisely. See Eval command and security issues.

Conditionals

Note: several standard POSIX utilities can be used for lexical comparisons. The examples below return a true (zero) exit status if the content of $a sorts before $b.

• awk -v v1="$a" -v v2="$b" 'BEGIN { exit !(v1 "" < "" v2) }'

• expr "x$a" "<" "x$b" >/dev/null

• printf "%s\n" "x$a" "x$b" | sort -c >/dev/null 2>&1 (also returns true if $a and $b are equal)

Arithmetic

Redirections

Builtins

• echo -n or -e -- POSIX doesn't define any options, and furthermore allows echo -e to be the default behavior. Instead use printf "%s\n" (for normal echo) or printf "%b\n" (for echo -e); leave off the \n to simulate echo -n.

• printf -v is not defined by POSIX. Also the %q format is not defined by POSIX.

• read -- the only option defined by POSIX is -r; ksh has a different set of options that only partially overlaps with bash.

• shopt, and therefore all the options it provides (extglob, nullglob, dotglob, etc.) are not defined by POSIX and are bash-specific

• local -- there is no POSIX equivalent. You can use $funcname_varname to reduce the likelihood of conflicts, but even that is not enough for recursive functions. You can ensure that recursive calls occur in subshell environments (so there is a "local" copy of all variables), or pass all "local variables" as parameters (because the positional parameters $@, $1, $2, etc are truly local). dash explicitly supports local as a non-Posix extension; ksh uses typeset instead, which works like bash's declare.

Special Variables

More

• The bash manual has a list of the differences between bash running in POSIX mode and a normal bash.

Note that bash in POSIX mode is only guaranteed to run a shell written according to the POSIX specification. It doesn't mean that it will fail if you use bashisms in your scripts.

• There is a handy perl script checkbashisms which is part of the debian devscripts package which can help point out bashisms in a particular script.

CategoryShell