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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 17 Oct 2010 19:11:15 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: "7225@debbugs.gnu.org" <7225@debbugs.gnu.org>
> 
> > 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?

No, you understand it correctly.

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

Right, these are in general two different groups.

> You seem to be assuming that the process group of the shell will
> include all of the shell's children.

No, I didn't assume that, sorry for possibly confusing wording.

There's a misunderstanding here: you were talking about the case of
interrupting a command run by a shell, whereas I was talking about the
case of sending a signal to a process that is not the shell, or
perhaps about signaling the shell itself.

For the case you ware talking about, sending the signal to the shell
is indeed the wrong thing, because the shell makes any foreground
command it runs into a separate process group, and it's that process
group that we want to send the signal to.  But for that case, you
already found the right solution: use SIGNALS_VIA_CHARACTERS.  This
does exactly the right thing, like the INTR character typed on the
tty.

What's left is the case of signals other that SIGINT/SIGQUIT/SIGTSTP.
In that case, in the absence of TIOCGPGRP, the code in process.c
supports sending the signal only to p->pid's process group (if p->pid
is not a group leader, only it itself will be signaled).  I think this
is better than punting, because if there _is_ a process group of which
p->pid is the leader, doing what the code does now will not leave
orphans, processes other than p->pid that belonged to p->pid's group.
It is true that this group might not be the foreground process group,
but with signals other than SIGINT/SIGQUIT/SIGTSTP, this matters much
less, I think.

Does this make sense?

If it does, then I think you should add SIGNALS_VIA_CHARACTERS, and
leave the rest unaltered, because that's the best Emacs can do if
TIOCGPGRP is not supported.

> > 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
> 
> 508 is the PID as well as the PGID of the shell.  But cat is in a 
> different process group, even though it's a child of the shell (as we 
> see from the PPID).  On the other hand, it has the same controlling tty 
> as the shell, so we'd be in business if we could get the PGID of the 
> foreground process of the controlling tty of the shell.  That's what I 
> thought emacs_get_tty_pgrp was doing (according to its comment).  When I 
> type C-c C-c, emacs sends a signal to PGID 508, which is not the right 
> thing to do.

For the case of a foreground command run by the shell, when we want to
interrupt that command, yes.  But that case is solved by using
SIGNALS_VIA_CHARACTERS.