Problem redirecting stderr to pipe in subprocess

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Tue Oct 11 00:18:00 GMT 2011


On Mon, Oct 10, 2011 at 05:02:18PM -0700, jan.kolar wrote:
>Christopher Faylor-8 wrote:
>> On Sun, Oct 09, 2011 at 07:58:15PM -0400, Christopher Faylor wrote:
>>>On Sat, Oct 08, 2011 at 05:39:20PM -0400, Ken Brown wrote:
>>>>Attached is a slight modification of the STC, in which I set stdin for 
>>>>the bash subprocess to /dev/null.  With this modification, the program 
>>>>works as expected (and as on Linux) with cygwin-1.7.9, but the same 
>>>>problem as before occurs with the latest snapshot.
>>>
>>>I can duplicate this problem.  I'll take a look.
>>>
>>>Thanks for the STC.
>> 
>> As far as I can tell, this is arguably a bug in bash.  It's also an
>> annoying compatibility problem between Linux and Cygwin.
>> 
>> When the tty layer in Cygwin was first developed, the model (either in
>> my head or in reality) was "If you don't have a tty and open a tty, that
>> becomes your controlling tty".  But, apparently that model changed over
>> time to something more sensical where you have to explicitly use
>> ioctl(TIOCSCTTY) to set up a controlling terminal.  On Linux systems
>> that would presumably be done via login(1).  We don't normally run login
>> on Cygwin, though.
>> 
>> The problem is that when there is no controlling tty, bash uses a
>> fallback mechanism to find the name of the tty by opening the tty
>> associated with fd 0.  It does this without setting the O_NOCTTY
>> flag and, so, the act of opening the fd assigns a controlling
>> terminal.
>> 
>> This is not a problem on Linux (or FreeBSD for that matter) but it is a
>> problem on Cygwin: it causes the aforementioned hang.  So, bash could be
>> modified to work around this issue but Cygwin is likely the only system
>> left with this problem.  So, I've modified Cygwin so that a controlling
>> tty is not assigned if the fd being opened is > 2.  There are still
>> pathological situations which will cause problems with that but, for
>> this particular problem, it seems to make bash behave better.
>> 
>> Oh, and the reason why bash was "hanging" is because, thanks to the
>> intracies of UNIX job control, it had received a SIGTSTP when an attempt
>> was made to output to a tty for which bash was not the process group
>> leader
>
>And how we can explain the hang does not happen on my machine ?
>Does (older) version of bash make that difference ?
>
>Windows 7, cygwin-1.7.9-1 (unmodified),
>GNU bash, version 3.2.49(23)-release (i686-pc-cygwin)

I'd explain it as "I don't care since you're running a different,
ancient version of bash".

cgf

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



More information about the Cygwin mailing list