== 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.