Re: bug with built-in commands in bash when redirecting output

[Eric Blake <ebb9 at byu dot net>]

Eric Blake <ebb9 <at> byu.net> writes:

> 
> I am suspecting a potential cygwin bug in fork().  Using the builtin echo, 
the 
> sequence is that bash creates the pipe, then forks, the forked child sees 
that 
> stdout is text mode, then rearranges fd's around so that the pipe is now 
> attached to stdout, all before any output occurs - but by then the damage is 
> done, since stdout remains in text mode.  Using /bin/echo is immune, because 
> the fork is followed by an exec() that starts from scratch, determines that 
> stdout is a pipe, and defaults back to binary mode.

The problem is that after a fork, there is no way for stdio to know when you 
have replaced the fd underlying one of std{in,out,err} unless you tell it.  On 
Linux, this isn't too bad of a problem (sure, if stdout is line-buffered, and 
you then replace the fd with a pipe, you have a slight performance drop when 
using stdout in the fork, but no one has really complained about this before).  
But on cygwin, when line endings are at stake, it matters.  A cooler fix would 
be coordinating between cygwin and newlib, such that any dup() that changes the 
underlying fd of an open stream will make the stream auto-detect the change.  
But I don't know if such a change is worth the effort; at any rate, my reading 
of POSIX is that the use of a stream (including stdout) after clobbering the 
underlying fd is in the realm of undefined territory.

> 
> I'll have to do further investigation, to see whether it is really bash's or 
> cygwin's fault (so far all I've done is look at straces), and even if it is 
> cygwin's fault, whether bash can work around it until a cygwin patch is 
> available.

So, I retract that it is a cygwin bug, and instead claim it is an upstream bash 
bug.  It is solved by doing freopen(NULL,"w",stdout) after replacing the fd, 
since that is the mechanism for telling stdio that it should please choose the 
correct text or binary mode based on the new underlying fd.  And while I don't 
know if upstream will accept this patch (after all, on Linux, no one seems to 
mind if stdout is slightly out-of-sync with reality after replacing the fd 
underneath it, and freopen(NULL) is not universally supported), I will 
certainly be releasing a patched version of cygwin bash in the near future.  I 
still hope to convert to a cygport build setup, and figure out how to make 
interactive exported SHELLOPTS play nicer with non-interactive shells, so it 
may be a few more days before I can release this patch.

-- 
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/