From: Eli Zaretskii <eliz@gnu.org>
To: Ken Brown <kbrown@cornell.edu>
Cc: 7225@debbugs.gnu.org
Subject: bug#7225: 23.2.50; [PATCH] C-c C-c doesn't work in shell mode (Cygwin)
Date: Mon, 18 Oct 2010 02:59:57 -0400 [thread overview]
Message-ID: <E1P7jhN-0004eE-4E@fencepost.gnu.org> (raw)
In-Reply-To: <4CBB8293.2020401@cornell.edu> (message from Ken Brown on Sun, 17 Oct 2010 19:11:15 -0400)
> 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.
next prev parent reply other threads:[~2010-10-18 6:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-15 23:36 bug#7225: 23.2.50; [PATCH] C-c C-c doesn't work in shell mode (Cygwin) Ken Brown
2010-10-16 7:32 ` Eli Zaretskii
2010-10-16 12:44 ` Ken Brown
2010-10-16 13:26 ` Eli Zaretskii
2010-10-16 18:22 ` Ken Brown
2010-10-17 21:40 ` Ken Brown
2010-10-17 22:08 ` Eli Zaretskii
2010-10-17 23:11 ` Ken Brown
2010-10-17 23:39 ` Ken Brown
2010-10-18 6:59 ` Eli Zaretskii [this message]
2010-10-18 11:58 ` Ken Brown
2010-10-18 17:37 ` Ken Brown
2010-10-18 5:49 ` Jan Djärv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1P7jhN-0004eE-4E@fencepost.gnu.org \
--to=eliz@gnu.org \
--cc=7225@debbugs.gnu.org \
--cc=kbrown@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.