0

I have a command: mywritercmd -f /tmp/test 2>&1 > log.txt I run in a bash terminal, the command returns error: could not open output file "/tmp/test": Permission denied

Nevertheless, this error message isn't written in the log.txt file, it stays empty...

Why?

I'd have guessed this message should go to stderr and then in the file but somehow it isn't.

None
  • 647
  • 1
    See https://unix.stackexchange.com/a/159514/117549 specifically the "left to right" part. You've redirected stderr to where stdout is/was, then redirected stdout to the log file. – Jeff Schaller Oct 25 '21 at 17:14
  • Yes it does. I didn't search enough to find this answered question. Thanks! – None Oct 26 '21 at 06:46

1 Answers1

6

Ordering causes the difference. The command line is evaluated from left to right. When it reaches 2>&1, the instruction is to deliver stderr to wherever stdout goes. At this point, the > log.txt part has not been evaluated yet. As a result, the stderr remains at the default, which is to output to the terminal.

mywritercmd -f /tmp/test > log.txt 2>&1 will result in the behaviour that you want, and cause the error message to be written to the log.txt file.

Haxiel
  • 8,361
  • This is the first time I've gotten a real explanation for this quirk. Intuitively it should be the reverse because we claim stderr is being redirected to stdout, but really it's to the destination of stdout. – davolfman Oct 25 '21 at 17:32
  • You can treat the "&" as meant the current location. So "2>&1 > /tmp/log.txt " means "send stderr to the current place stdout goes and then send stdout to log.txt" – Stephen Harris Oct 25 '21 at 17:52
  • 3
    Think of & as its meaning in C: the "address of" – glenn jackman Oct 25 '21 at 18:46
  • I mistakenly and unconsciously thought it would be processed from left to right (more or less like a pipe). 1. Run the command, 2. Redirect stderr to stdout, 3. stdout (with stderr) into a file. But I was wrong in the way all that works. Thanks! – None Oct 25 '21 at 19:12