A Bourne shell gotcha: redirection order

I was reminded of this by seeing it in a shell script recently: the order that you do redirection in on a command line can be important. This means that the following two lines are not equivalent:

foobar 2>&1 >/some/where
foobar >/some/where 2>&1

The first one sends standard error to wherever the current standard output is, and then sends standard output to /some/where; the latter sends both standard output and standard error to /some/where.

This (only) happens when you are redirecting to file descriptors, because the redirections are applied left to right and use the current 'value' of that file descriptor, even if the file descriptor will later be sent somewhere else by a later redirection.

This is unfortunately an easy mistake to make and a pernicious one to boot, since you may not notice it for a while (for example, if foobar produces errors only rarely).

Sidebar: more redirection idioms

While I'm writing this stuff down, there's some common Bourne shell redirection idioms that are worth remembering:

echo error message 1>&2

This redirects error messages from shell scripts to standard error, where they should go.

exec >/some/where 2>&1

This redirects all further output from the script and things it runs to /some/where. (You can obviously use it to redirect just stdout or stderr alone, as desired.)

You can play rather obscure tricks by using high file descriptors in creative ways. For example, the following ugly incantation swaps standard output and standard error:

foobar 5>&2 2>&1 1>&5 5>&-

This has the defect that it destroys file descriptor 5, which hopefully wasn't already being used for anything important.