public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* /dev/stderr problem
@ 2016-10-17  6:34 Thorsten Kampe
  2016-10-17 13:51 ` Thorsten Kampe
  0 siblings, 1 reply; 4+ messages in thread
From: Thorsten Kampe @ 2016-10-17  6:34 UTC (permalink / raw)
  To: cygwin

Hi,

the following bash script results in a different output when 
redirected to a file.

```
printf "FIRST LINE\n" > /dev/stderr
shopt -os xtrace
printf "SECOMD LINE\n" > /dev/stderr
```

```
$ bash script.sh
FIRST LINE
+ printf 'SECOMD LINE\n'
SECOMD LINE
```

```
$ bash script.sh 2> file && cat file
SECOMD LINE
```

When I use `>&2` instead of `> /dev/stderr` the problem does not 
occur.

Since this problem does not occur on Linux but also with Zsh on 
Cygwin, I think this is a Cygwin issue.

Thorsten


--
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] 4+ messages in thread

* Re: /dev/stderr problem
  2016-10-17  6:34 /dev/stderr problem Thorsten Kampe
@ 2016-10-17 13:51 ` Thorsten Kampe
  2016-10-17 18:11   ` Eric Blake
  0 siblings, 1 reply; 4+ messages in thread
From: Thorsten Kampe @ 2016-10-17 13:51 UTC (permalink / raw)
  To: cygwin

* Thorsten Kampe (Mon, 17 Oct 2016 08:25:13 +0200)

> the following bash script results in a different output when 
> redirected to a file.
> 
> ```
> printf "FIRST LINE\n" > /dev/stderr
> shopt -os xtrace
> printf "SECOMD LINE\n" > /dev/stderr
> ```

On further inspection: the `xtrace` is not related to the problem:

script.sh
```
printf "FIRST LINE\n" > /dev/stderr
printf "SECOMD LINE\n" > /dev/stderr
```

```
$ bash script.sh
FIRST LINE
SECOMD LINE

$ bash script.sh 2> file && cat file
SECOMD LINE

$ file /dev/stderr
/dev/stderr: symbolic link to /proc/self/fd/2
```

Thorsten


--
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] 4+ messages in thread

* Re: /dev/stderr problem
  2016-10-17 13:51 ` Thorsten Kampe
@ 2016-10-17 18:11   ` Eric Blake
  2016-10-17 18:29     ` Linda Walsh
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Blake @ 2016-10-17 18:11 UTC (permalink / raw)
  To: cygwin


[-- Attachment #1.1: Type: text/plain, Size: 857 bytes --]

On 10/17/2016 01:32 AM, Thorsten Kampe wrote:
> * Thorsten Kampe (Mon, 17 Oct 2016 08:25:13 +0200)
> 
>> the following bash script results in a different output when 
>> redirected to a file.
>>
>> ```
>> printf "FIRST LINE\n" > /dev/stderr
>> shopt -os xtrace
>> printf "SECOMD LINE\n" > /dev/stderr

Cygwin treats '> /dev/stderr' as a request to truncate /dev/stderr (or,
for that matter, any opening of a file under /proc/self/fd).  Other
platforms treat that as a special file that can never be truncated, but
is instead reopened at the same offset.

Maybe cygwin can be taught that opening a file through /proc/self/fd
should preserve rather than reset offsets, but it will be a tricky
patch, and someone has to write it.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: /dev/stderr problem
  2016-10-17 18:11   ` Eric Blake
@ 2016-10-17 18:29     ` Linda Walsh
  0 siblings, 0 replies; 4+ messages in thread
From: Linda Walsh @ 2016-10-17 18:29 UTC (permalink / raw)
  To: cygwin

Eric Blake wrote:
> On 10/17/2016 01:32 AM, Thorsten Kampe wrote:
>> * Thorsten Kampe (Mon, 17 Oct 2016 08:25:13 +0200)
>>
>>> the following bash script results in a different output when 
>>> redirected to a file.
>>>
>>> ```
>>> printf "FIRST LINE\n" > /dev/stderr
>>> shopt -os xtrace
>>> printf "SECOMD LINE\n" > /dev/stderr
> 
> Cygwin treats '> /dev/stderr' as a request to truncate /dev/stderr (or,
> for that matter, any opening of a file under /proc/self/fd).  Other
> platforms treat that as a special file that can never be truncated, but
> is instead reopened at the same offset.
> 
> Maybe cygwin can be taught that opening a file through /proc/self/fd
> should preserve rather than reset offsets, but it will be a tricky
> patch, and someone has to write it.
---
Is /dev/stderr a POSIX special name that one should expect that rewinding
is disallowed or ignored?

Good analysis, BTW, that sure would have puzzled me.
-l


> 

--
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] 4+ messages in thread

end of thread, other threads:[~2016-10-17 18:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-17  6:34 /dev/stderr problem Thorsten Kampe
2016-10-17 13:51 ` Thorsten Kampe
2016-10-17 18:11   ` Eric Blake
2016-10-17 18:29     ` Linda Walsh

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).