Mail Archives: cygwin/2011/07/25/13:06:40
On Mon, Jul 25, 2011 at 06:55:06PM +0200, Marco Atzeri wrote:
>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.
>
>except if bash is sleeping and waiting for signal (or sort of)
>
>http://www.gnu.org/software/bash/manual/bashref.html#Signals
"sleeping and waiting for signal" would mean that "bash is not waiting
for input". If bash isn't waiting for input that would explain the
problem. However, I would expect that bash, in this scenario, to be
waiting for input. I was hoping you'd provide insight into whether that
was the case or not.
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
- Raw text -