X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_CG,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
Message-ID:	<4E2D9FEA.1020900@gmail.com>
Date:	Mon, 25 Jul 2011 18:55:06 +0200
From:	Marco Atzeri <marco DOT atzeri AT gmail DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: SIGHUP on pty closure
References:	<4E289D7B DOT 4050103 AT gmail DOT com> <4E2D474A DOT 4000509 AT gmail DOT com> <20110725151140 DOT GA27310 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To:	<20110725151140.GA27310@ednor.casa.cgf.cx>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.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 25/07/2011 17.11, Christopher Faylor wrote:
> On Mon, Jul 25, 2011 at 12:36:58PM +0200, Marco atzeri wrote:
>> On 7/21/2011 11:43 PM, Marco atzeri wrote:
>>> looking on the mc subshell issue, I found that mc
>>> suppose that the subshell will receive a SIGHUP
>>> when mc exit and close the master side of pty.
>>>
>>> Is such assumption wrong or it is a missing piece of
>>> cygwin pty implementation ?
>>>
>>>
>>>
>>> ------------- extract from subshell.c --------------
>>> /* Attach all our standard file descriptors to the pty */
>>>
>>> /* This is done just before the fork, because stderr must still */
>>> /* be connected to the real tty during the above error messages; */
>>> /* otherwise the user will never see them. */
>>>
>>> dup2 (subshell_pty_slave, STDIN_FILENO);
>>> dup2 (subshell_pty_slave, STDOUT_FILENO);
>>> dup2 (subshell_pty_slave, STDERR_FILENO);
>>>
>>> close (subshell_pipe[READ]);
>>> close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in
>>> case... */
>>> /* Close master side of pty. This is important; apart from */
>>> /* freeing up the descriptor for use in the subshell, it also */
>>> /* means that when MC exits, the subshell will get a SIGHUP and */
>>> /* exit too, because there will be no more descriptors pointing */
>>> /* at the master side of the pty and so it will disappear. */
>>> close (subshell_pty);
>>>
>>> /* Execute the subshell at last */
>>>
>>> switch (subshell_type)
>>> {
>>> case BASH:
>>> execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
>>> break;
>>> ----------------------------------------------------------
>>
>> It seems that mc is correct in the expectation.
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html
>>
>> "If fildes refers to the master side of a pseudo-terminal, and this is
>> the last close, a SIGHUP signal shall be sent to the controlling
>> process, if any, for which the slave side of the pseudo-terminal is the
>> controlling terminal. It is unspecified whether closing the master side
>> of the pseudo-terminal flushes all queued input and output."
>>
>>
>> I don't find such implementation on cygwin
>>
>> fhandler_pty_master::close ()
>>
>> Am I looking in the wrong place ?
>
> (checked into this a little more)
>
> Sort of.  If the process is doing a read, it is supposed to detect that
> the tty has been closed and a SIGHUP is supposed to be sent.  It is not
> precisely the same thing as sending a SIGHUP when the master closes but
> I'm surprised that, in principle, it doesn't amount to the same thing.
>
> Just see any of the SIGHUPs in fhandler_tty.cc.  They are all supposed
> to be dealing with this scenario.
>
> So, unless bash is not waiting for input (which is unlikely) this should
> work.
>
> cgf

except if bash is sleeping and waiting for signal (or sort of)

http://www.gnu.org/software/bash/manual/bashref.html#Signals

The fact that sending SIGHUP (with $kill -SIGHUP bashpid)
triggers the bash exit, it seems an indication that cygwin is not
correctly handling the situation.

Otherwise there is a bug in bash, and not in mc ;-)

Marco



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

- Raw text -