Re: /dev/stderr problem
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
Re: /dev/stderr problem
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 signature.asc Description: OpenPGP digital signature
Re: /dev/stderr problem
* 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
/dev/stderr problem
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
