Redirection to stderr

Hans-Bernhard Bröker
Mon Jul 10 18:43:00 GMT 2017

Am 10.07.2017 um 14:01 schrieb cygwin-mailinglist:
> On Mon, July 10, 2017 12:33, Marco Atzeri wrote:

>> Redirecting something on itself it is not guarantee to work.

> I'm not sure it is on itself. Are these not two different streams?
> When "some-cmd 2> /dev/stderr" is interpreted by the shell I would expect
> that /dev/stderr points to a pipe or terminal *of that shell*. The fd 2 in
> "2>", on the other hand, should be the standard error stream *of
> some-cmd*. 

And what did you think that file descriptor of some-cmd would have been 
without that redirection?  I.e. where would some-cmd have got its stderr 
stream from?  The answer is: the shell will pass on a dup()licate of its 
own stderr channel, which in turn is identical to /dev/stderr.

I.e. what that contraption would do, if it worked, would be a no-op.

> The redirection plugs the two together. Similar reasoning
> applies to the outer layers of the redirection onion. Each process has a
> /dev/stderr which stays (or, rather, should stay) valid until that process
> ends. 

Not really.  Processes _can_ close their std streams, if they want.

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list