stdin, stderr, redirection and logs
Yes, there is a difference.
/home/user/script.sh >> /home/user/stdout_and_error.log 2>&1
This will send both STDOUT and STDERR to /home/user/stdout_and_error.log
.
/home/user/script.sh 2>&1 >> /home/user/stdout_and_error.log
This will send STDOUT to /home/user/stdout_and_error.log
, and STDERR to what was previously STDOUT.
When you perform a shell redirection, the left side of the redirection goes to where the right side of the redirection currently goes. Meaning in 2>&1
, it sends STDERR (2) to wherever STDOUT (1) currently goes.
But if you afterwards redirect STDOUT somewhere else, STDERR doesn't go with it. It continues to go wherever STDOUT was previously going. This is why in your first example, both STDOUT and STDERR will go to the same place, but in the second they won't.
On the first command line, the shell sees >> file first and append stdout to file . Next 2>&1 sends fd2 ( stderr ) to the same place fd1 is going - that's to the file. And that's what you want.
On the second command line, the shell sees 2>&1 first. That means "make the standard error (file descriptor 2) go to the same place as the standard output (fd1) is going." There's no effect because both fd2 and fd1 are already going to the terminal. Then >> file appends fd1 ( stdout ) to file . But fd2 ( stderr ) is still going to the terminal.
>>
Appending stdout (stream #1) to a file.
2>&1
Combining stderr (stream #2) with stdout (stream #1) (Adds stderr into stdout)
>
Writes stdout (stream #1) to a file, overwriting the file.
1>
Writes stdout (stream #1) to a file, overwriting the file. Same as above.
2>
Writes stderr (stream #2) to a file, overwriting the file.
+++
You're first example would append stdout to a file, then add stderr to stdout.
You're second example would add stderr to stdout, then append the combined stdout (with stderr included) to a file.