Even without any redirection, or with nothing but >logfile 2>&1, you're not guaranteed to see output in order of generation.
For starters, the stdout from the application will be line-buffered (to tty) or buffered (to a pipeline) but stderr is unbuffered, so relationships between the order of output are broken as far as a reader is concerned. Subsequent stages in any pipeline you could concoct will not get deterministically ordered access to the two streams (they are conceptually things happening in parallel, and you're always subject to the scheduler - if by the time your reader gets a slice the writer has already written to both pipes, you cannot tell which came first).
"[T]he order they happen" is only really known to the application. Ordering of output across stdout/stderr is a well-known - classic, perhaps - problem.
As for a solution to redirect lots of command at once:
#!/bin/bash
{
somecommand
somecommand2
somecommand3
} 2>&1 | tee -a $DEBUGLOG
Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.
On the point of view of somecommand, its standard output goes into a pipe connected to tee and the standard error goes into the same file/pseudofile as the standard error of the shell, which you redirect to the standard output of the shell, which will be the console if you run your program from the console.
The one true way to explain it is to see what really happens:
Your shell's original environment might look like this if you run it from the terminal:
stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42
After you redirect standard error into standard output (exec 2>&1), you ... basically change nothing. But if you redirect the script's standart output to a file, you would end up with an environment like this:
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42
Then redirecting the shell standard error into standard output would end up like this :
stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file
Running a command will inherit this environment. If you run a command and pipe it to tee, the command's environment would be :
stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file
So your command's standard error still goes into what the shell uses as its standard error.
You can actually see the environment of a command by looking in /proc/[pid]/fd: use ls -l to also list the symbolic link's content. The 0 file here is standard input, 1 is standard output and 2 is standard error. If the command opens more files (and most programs do), you will also see them. A program can also choose to redirect or close its standard input/output and reuse 0, 1 and 2.
Best Answer
teecan't directly output to a file descriptor, but you can use process substitution withcatto solve it:So, stdout goes to the output through fd3, and both stdout and stderr go the log.