Re: Redirection to stderr

Re: Redirection to stderr

[Marco Atzeri]

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

Re: Redirection to stderr

[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?

> 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

Re: Redirection to stderr

[Andrey Repin]

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

Re: Redirection to stderr

[Peter Schneider]

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

Re: Redirection to stderr

[Eliot Moss]

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

Re: Redirection to stderr

[Hans-Bernhard Bröker]

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