bug#7225: 23.2.50; [PATCH] C-c C-c doesn't work in shell mode (Cygwin)

[Ken Brown <kbrown@cornell.edu>]

On 10/17/2010 7:11 PM, Ken Brown wrote:
> On 10/17/2010 6:08 PM, Eli Zaretskii wrote:
>>> Date: Sun, 17 Oct 2010 17:40:39 -0400
>>> From: Ken Brown<kbrown@cornell.edu>
>>> CC: "7225@debbugs.gnu.org"<7225@debbugs.gnu.org>
>>>
>>> I haven't yet found an alternative to TIOCGPGRP that works for Cygwin,
>>> and it may well be that there isn't one.  But I think there's a separate
>>> issue that is not specific to Cygwin.  It seems to me that line 6233 of
>>> process.c is simply wrong, and not just for Cygwin.
>>>
>>> When we reach that line, we want the process group ID of the foreground
>>> process group of the terminal associated with p (which is a shell in the
>>> most common use case).  We don't have TIOCGPGRP, so we don't know how to
>>> do this.  We therefore give up and set gid = p->pid.  Is there any
>>> situation in which this is the right thing to do?  It means that (in the
>>> common use case) we'll send the signal to the shell instead of to the
>>> process running in the shell.  Wouldn't it be better to just return at
>>> that point and issue a warning message saying that we can't send the signal?
>>
>> The problem that code is trying to solve is how to send a signal to
>> the whole process group starting at the shell (or whatever process is
>> the group leader).  Failure to do so could mean that the immediate
>> subprocess of Emacs will get the signal, but its children will not.
>> If the signal kills the subprocess, its children may remain behind as
>> orphans.
>
> Am I misunderstanding the comment preceding the definition of
> emacs_get_tty_pgrp?  Here's what it says:
>
> /* Return the foreground process group for the tty/pty that
>      the process P uses.  */
>
> That's not the same as the process group of the shell, at least in
> Cygwin.  See below.  You seem to be assuming that the process group of
> the shell will include all of the shell's children.  Is that what
> happens in GNU/Linux?
>
>>> What this would mean for Cygwin, once I make the change I proposed (and
>>> assuming I don't find a better solution), is that the only signals we'll
>>> be able to send to the foreground process of a shell are SIGINT,
>>> SIGQUIT, and SIGTSTP, and we'll see a failure message if we try to send
>>> a different signal.  That's better than sending a signal to the wrong
>>> process.
>>
>> It's not the wrong process.  The problem is that its children might
>> not get the signal.
>
> It is the wrong process on Cygwin.  Here's an example.  I start a shell
> and then run 'cat'.  In another shell I run 'ps'.  The relevant part of
> the output is:
>
>         PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>         508     920     508       3552    1 1009 18:50:15 /usr/bin/sh
> I     916     508     916       1832    1 1009 18:50:18 /usr/bin/cat

I've just checked that the same thing happens in GNU/Linux (or at least 
in the GNU/Linux system I have access to).  Start a shell, start 'cat', 
and the PGID of cat will not be the same as that of the shell.