This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem redirecting stderr to pipe in subprocess

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

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]