The shell ties the prior program's (or user input to the first) output to the input of the next program. That's (old) stdout and (new) stdin taken care of.
stderr is sent to the terminal as output by default.
For reference stdin, stdout, and stderr are normally numbered 0 through 2 respectively. When you're directing input and output on the shell (usually) the default is to wire up things as they'd make sense, but (without any IFS characters) a number on either side of the redirection operator codes tells the shell to grab a different input or output.
These will yield different results due to left to right parsing:
echo test >/tmp/test 2>&1
echo test 2>&1 >/tmp/test
In the second if there were any errors they'd be sent to the file, while in the first (assuming you can make temporary files, which normally you can) there won't be any errors printed but they would be sent as standard output on the shell.
Here's a more interesting example
echo test >/dev/null/test 2>/dev/null
echo test 2>/dev/null >/dev/null/test
The second line will silently fail (though it'll still return an exit value of 1) because the standard error output was already sent to /dev/null, while the first attempts to open a file that can't exist and prints the failure message before the error output is redirected.
Here's a cheat sheet which should cover the most common situations.
Send stdout to a file.
ls myFileWhichExists > myStdLog
- or -
ls myFileWhichExists 1> myStdLog
Send stderr to a file.
ls myFileWhichDoesNotExist 2> myErrLog
Send stdout to one file and stderr to a different file.
ls myFileWhichExists myFileWhichDoesNotExist 1> myStdLog 2> myErrLog
Send stdout and stderr to the same file
ls myFileWhichExists myFileWhichDoesNotExist 1> myBothLog 2>&1
I read that last part "2>&1" as "Send stderr (2) to the same place as stdout (1) is already going to".
Notice that if you send stdout and stderr to the same file, because of caching and other issues, the output from stdout and stderr will overlap in unpredictable ways.
