* Re: Redirection to stderr [not found] <baa3a4f84968dd6aa9869d2c9f58197f.squirrel@mail.schneiderp.de> @ 2017-07-10 10:33 ` Marco Atzeri 2017-07-10 12:02 ` cygwin-mailinglist 0 siblings, 1 reply; 6+ messages in thread From: Marco Atzeri @ 2017-07-10 10:33 UTC (permalink / raw) To: cygwin-mailinglist, cygwin On 10/07/2017 11:06, cygwin-mailinglist wrote: > Hi Marco, > > thanks for your reply. I'm mailing you personally because at first I only > subscribed to the mailing list digest (so I didn't receive your response > directly) and cannot or don't know yet how to reply to your mail to the > list which I only see in the web archive.-- reply to both. > As to your question: The redundant redirection of "stderr to itself" > appears in the context of a larger system of scripts which permit > configuring the destination of the redirection. The original reads > something like ''2> "$STDERR_TARGET"''. The elegance is that I can > configure where diagnostic output goes by simply setting an environment > variable. The scripts simply use whatever "file system location" (possibly > /dev/stderr) is configured. > > Rationale aside, it is a bug, isn't it? I guess a side effect of a lost race. Redirecting something on itself it is not guarantee to work. > Peter Marco -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redirection to stderr 2017-07-10 10:33 ` Redirection to stderr Marco Atzeri @ 2017-07-10 12:02 ` cygwin-mailinglist 2017-07-10 13:05 ` Andrey Repin 2017-07-10 18:43 ` Hans-Bernhard Bröker 0 siblings, 2 replies; 6+ messages in thread From: cygwin-mailinglist @ 2017-07-10 12:02 UTC (permalink / raw) To: Marco Atzeri; +Cc: cygwin On Mon, July 10, 2017 12:33, Marco Atzeri wrote: > > On 10/07/2017 11:06, cygwin-mailinglist wrote: [...] >> Rationale aside, it is a bug, isn't it? > > I guess a side effect of a lost race. Which race, exactly? > 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*. 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. If there is a redirection, the inner process (e.g. some-cmd) must not "free" or "delete" the pipe or whatever it is now attached to upon exit; that stream belongs to the caller, e.g. the shell. -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redirection to stderr 2017-07-10 12:02 ` cygwin-mailinglist @ 2017-07-10 13:05 ` Andrey Repin 2017-07-10 13:41 ` Peter Schneider 2017-07-10 18:43 ` Hans-Bernhard Bröker 1 sibling, 1 reply; 6+ messages in thread From: Andrey Repin @ 2017-07-10 13:05 UTC (permalink / raw) To: cygwin-mailinglist, cygwin Greetings, cygwin-mailinglist! > On Mon, July 10, 2017 12:33, Marco Atzeri wrote: >> >> On 10/07/2017 11:06, cygwin-mailinglist wrote: > [...] >>> Rationale aside, it is a bug, isn't it? >> >> I guess a side effect of a lost race. > Which race, exactly? echo aaa > a cat a > a >> Redirecting something on itself it is not guarantee to work. > I'm not sure it is on itself. Are these not two different streams? No. -- With best regards, Andrey Repin Monday, July 10, 2017 15:54:58 Sorry for my terrible english... -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redirection to stderr 2017-07-10 13:05 ` Andrey Repin @ 2017-07-10 13:41 ` Peter Schneider 2017-07-10 16:32 ` Eliot Moss 0 siblings, 1 reply; 6+ messages in thread From: Peter Schneider @ 2017-07-10 13:41 UTC (permalink / raw) To: cygwin On Mon, July 10, 2017 14:55, Andrey Repin wrote: > Greetings, cygwin-mailinglist! > >> On Mon, July 10, 2017 12:33, Marco Atzeri wrote: >>> >>> On 10/07/2017 11:06, cygwin-mailinglist wrote: >> [...] >>>> Rationale aside, it is a bug, isn't it? >>> >>> I guess a side effect of a lost race. > >> Which race, exactly? > > echo aaa > a > cat a > a The problem with "cat a > a" is entirely unrelated to "some-cmd 2>/dev/stderr". (Apart from /dev/stderr not being a regular file, some-cmd does not receive a path argument which it tries to open, the way "cat a" does.) -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redirection to stderr 2017-07-10 13:41 ` Peter Schneider @ 2017-07-10 16:32 ` Eliot Moss 0 siblings, 0 replies; 6+ messages in thread From: Eliot Moss @ 2017-07-10 16:32 UTC (permalink / raw) To: cygwin On 7/10/2017 9:41 AM, Peter Schneider wrote: > On Mon, July 10, 2017 14:55, Andrey Repin wrote: >> Greetings, cygwin-mailinglist! >> >>> On Mon, July 10, 2017 12:33, Marco Atzeri wrote: >>>> >>>> On 10/07/2017 11:06, cygwin-mailinglist wrote: >>> [...] >>>>> Rationale aside, it is a bug, isn't it? >>>> >>>> I guess a side effect of a lost race. >> >>> Which race, exactly? >> >> echo aaa > a >> cat a > a > > The problem with "cat a > a" is entirely unrelated to "some-cmd > 2>/dev/stderr". (Apart from /dev/stderr not being a regular file, some-cmd > does not receive a path argument which it tries to open, the way "cat a" > does.) Understanding what is happening would require figuring out which process opens /dev/stderr and when. However, there is another approach that might get at what you want: /proc/nnnn/fd/2 gives access to file descriptor 2 (standard error) of process number nnnn. If you can get the right pid, and you have access rights, then you can open that. Here the PPID environment variable may be useful. Which stderr is it you're hoping the output will go to? Regards - EM -- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redirection to stderr 2017-07-10 12:02 ` cygwin-mailinglist 2017-07-10 13:05 ` Andrey Repin @ 2017-07-10 18:43 ` Hans-Bernhard Bröker 1 sibling, 0 replies; 6+ messages in thread From: Hans-Bernhard Bröker @ 2017-07-10 18:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-07-10 18:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <baa3a4f84968dd6aa9869d2c9f58197f.squirrel@mail.schneiderp.de> 2017-07-10 10:33 ` Redirection to stderr Marco Atzeri 2017-07-10 12:02 ` cygwin-mailinglist 2017-07-10 13:05 ` Andrey Repin 2017-07-10 13:41 ` Peter Schneider 2017-07-10 16:32 ` Eliot Moss 2017-07-10 18:43 ` Hans-Bernhard Bröker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).