As of 4.3.30 (jessie), the critical passage in the documentation has been slightly reworded:
"If |& is used, command's standard error, in addition to its standard output, is connected to command2's standard input through the pipe;" But it's still not correct. The point is, "|&" does *not* connect the command's standard error to the pipe. It connects it to its standard output *after* all other redirections. *Before* those redirections, that would be the pipe, but after them, it may or may not be. I.e. what seems to happen is: 1. redirect stdout to the pipe 2. do all explicit redirections 3. redirect stderr to stdout So stdout and stderr are handled fundamentally differently, whereas the wording above makes it sound like they're handled the same way. Consider again the example from my original report: % sh -c 'echo stdout; echo stderr >&2' > /dev/null |& cat Outputs nothing, so the explicit redirection of stdout also affects stderr. In contrast to: % sh -c 'echo stdout; echo stderr >&2' 2> /dev/null |& cat stdout stderr So the explicit redirection of stderr has no effect. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
