This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem redirecting stderr to pipe in subprocess
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
>> 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
>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".
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple