This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Redirection to stderr


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]