X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 11 Oct 2011 14:17:42 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem redirecting stderr to pipe in subprocess
Message-ID: <20111011121742.GC21554@calimero.vinschen.de>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20111010220608.GA1568@ednor.casa.cgf.cx>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Oct 10 18:06, Christopher Faylor 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.

I don't quite understand this.  The "If you don't have a tty and open a tty,
that becomes your controlling tty" is standard POSIX behaviour, isn't it?
SUSv4 open writes:

  O_NOCTTY

    If set and path identifies a terminal device, open() shall not
    cause the terminal device to become the controlling terminal for
    the process. If path does not identify a terminal device,
    O_NOCTTY shall be ignored.

The Linux man page contains basically the same.

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

That sounds correct to me.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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