From: Ken Brown <kbrown@cornell.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "7225@debbugs.gnu.org" <7225@debbugs.gnu.org>
Subject: bug#7225: 23.2.50; [PATCH] C-c C-c doesn't work in shell mode (Cygwin)
Date: Sun, 17 Oct 2010 19:39:59 -0400 [thread overview]
Message-ID: <4CBB894F.8010203@cornell.edu> (raw)
In-Reply-To: <4CBB8293.2020401@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.
next prev parent reply other threads:[~2010-10-17 23:39 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 [this message]
2010-10-18 6:59 ` Eli Zaretskii
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=4CBB894F.8010203@cornell.edu \
--to=kbrown@cornell.edu \
--cc=7225@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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.