Date: Mon, 10 Oct 2011 18:06:08 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem redirecting stderr to pipe in subprocess
Message-ID: <20111010220608.GA1568@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4E906DD1 DOT 50107 AT cornell DOT edu> <4E90C308 DOT 9090508 AT cornell DOT edu> <20111009235815 DOT GA18203 AT ednor DOT casa DOT cgf DOT cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20111009235815.GA18203@ednor.casa.cgf.cx>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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

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