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: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
