This redirection is meant to also write the stderr
output into the server log.
When you use a redirection like
some command > file.txt
It only saves output written by the program to stdout
, the standard output stream usually connected to the console.
Most programs, however, adhere to the good practice of writing error messages to a different output stream, stderr
, which while also printed on the console, can be "catched" and redirected separately in order to ensure error messages don't get overlooked in "verbose" normal output of the program.
This can however also become a problem: if you only redirect the "normal" output of some lengthy (and thus usually unattended) compile process, e.g., into a file, warnings and errors will only be printed to the console. If now you later come back to inspect the results, you will have standard "everything ok" output in your log file, and seemingly uncorrelated error output in your console.
Therefore, it can be helpful to "also redirect" the error output to the file, so that all messages are "in context".
The mechanism here is to
first redirect stdout
to a file (the command > file
part, which explicitly could be written as command 1>file
, the 1
indicating the file descriptor of the stdout
stream)
redirect the stderr
in a "merging" way to stdout
, too (that is why the syntax is 2>&1
, the &
meaning "copy" the file descriptor), well-knowing that the stdout
is already redirected to a file.
A good place for further reading might be
2>&1
is: redirect stderr (2) to where stdout (1) is currently going. Not currently is is currently going to the file, as we are processing left to right, we have already directed stdout to the file. – ctrl-alt-delor Jan 29 '20 at 10:19