Apparently, too many people don’t understand Bash redirection. They might get the basic syntax, but they think of the process as declarative; in Bourne-ish shells, it is procedural.
In Bash, streams are handled in terms of “file descriptors” of “FDs”.
FD 0 is stdin, FD 1 is stdout, and FD 2 is stderr. The equivalence (or
lack thereof) between using a numeric file descriptor, and using the
associated file in
interesting, but beyond the scope of this article.
Step 1: Pipes
To quote the Bash manual:
A 'pipeline' is a sequence of simple commands separated by one of the control operators '|' or '|&'. The format for a pipeline is [time [-p]] [!] COMMAND1 [ [| or |&] COMMAND2 ...]
|& is just shorthand for
2>&1 |, the pipe part happens here, but the
2>&1 part doesn’t happen until step 2.
First, if the command is part of a pipeline, the pipes are set up.
For every instance of the
| metacharacter, Bash creates a
pipe(3)), and duplicates (
write end of the pipe to FD 1 of the process on the left side of the
|, and duplicate the read end of the pipe to FD 0 of the
process on the right side.
Step 2: Redirections
After the initial FD 0 and FD 1 fiddling by pipes is done, Bash looks at the redirections. This means that redirections can override pipes.
Redirections are read left-to-right, and are executed as they are
dup2(right-side, left-side). This is where most
of the confusion comes from, people think of them as declarative, which
leads to them doing the first of these, when they mean to do the
cmd 2>&1 >file # stdout goes to file, stderr goes to stdout cmd >file 2>&1 # both stdout and stderr go to file