Date: Mon, 10 Oct 2011 20:17:40 -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: <20111011001740.GC23672@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> <20111010220608 DOT GA1568 AT ednor DOT casa DOT cgf DOT cx> <32628212 DOT post AT talk DOT nabble DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <32628212.post@talk.nabble.com>
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 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