4 ms·
A gotcha for me originally and perhaps others is that while using ordering like $ ./outerr >blah 2>&1 sends stdout and stderr to blah, imitating the order
by emmelaich 8mo ago
A gotcha for me originally and perhaps others is that while using ordering like
$ ./outerr >blah 2>&1
sends stdout and stderr to blah, imitating the order with pipe instead does not.
$ ./outerr | 2>&1 cat >blah
err
This is because | is not a mere redirector but a statement terminator.
(where outerr is the following...)
echo out
echo err >&2
- inigyou 8mo agoWhy would that second one be expected to work?
- time4tea 8mo agoUseless use of cat error/award But also | isnt a redirection, it takes stdout and pipes it to another program. So, if you want stderr to go to stdout, so you can pipe it, you need to do it in order. bob 2>&1 | prog You usually dont want to do this though.
- kazinator 8mo agoThe point is that the order in which that is processed is not left to right. First the | pipe is established as fd [1]. And then 2>&1 duplicates that pipe into [2]. I.e. right to left: opposite to left-to-right processing of redirections. When you need to capture both standard error and standard output to a file, you must have them in this order: bob > file 2>&1 It cannot be: bob 2>&1 > file Because then the 2>&1 redirection is performed first (and usually does nothing because stderr and stdout are already the same, pointing to your terminal). Then > file redirects only stdout. But if you change > file to | process, then it's fine! process gets the combined error and regular output.
- murphyslaw 8mo agoYou can pipe the fd directly: # echo 1 >&2 2>| echo
- emmelaich 8mo agoTry it without the `cat` and tell me what you get.