Re: Sending signals to a subprocess
On 24 October 2010 03:51, Ken Brown wrote: On 10/20/2010 4:32 PM, Christopher Faylor wrote: I think I'm seeing some pattern to the way Linux handles [tcgetpgrp] and I should be able to make Cygwin work the same way. This seems to be fixed in the latest snapshot, as far as emacs is concerned. Works for mintty too. Thanks very much! I no longer see any difference between Cygwin and Linux there. I also get the expected results when I run the test cases that Andy posted. But when I run the original test case that you posted in http://cygwin.com/ml/cygwin/2010-10/msg00395.html I'm getting strange behavior. I ran it with no argument, getting 0 = tcgetpgrp(4) 0 = ioctl(fd, TIOCGPGRP, pid), pid = 0 but then the terminal seemed to hang, and I didn't get a new prompt. I tried this both in mintty and xterm. It worked for me a couple of times before I got the hang. Locking trouble? Andy -- 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
Re: Sending signals to a subprocess
On Sat, Oct 23, 2010 at 10:51:38PM -0400, Ken Brown wrote: On 10/20/2010 4:32 PM, Christopher Faylor wrote: On Wed, Oct 20, 2010 at 08:25:37PM +0100, Andy Koppe wrote: On 20 October 2010 13:20, Andy Koppe wrote: Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she saw Linux doing that. ??But when I run Corinna's test on my Linux system, I get -1 where she got 0. ??So not all Linuxes agree on what tcgetpgrp should do. Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before the child is forked and after it exited, so it's correct to report that there's no foreground process. I wonder which Linux it was that returned 0 in case of failure. I've tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and also a Debian with a 2.4 kernel, and got -1 on all of those. Actually I'd only tried my test on all three systems, whereas I'd tried Corinna's only on the old Redhat, where it did print -1 for failure. On the 2.4 system it can't open /dev/ptmx, whereas on the Opensuse with 2.6.34 I do get the results Corinna reported, including 0 on the master side of the pty when enquiring from the parent. (Process 0 is the startup process, so I guess that makes some sense.) To bring my ramblings to some sort of conclusion, here's a slightly amended version of Corinna's test that checks the master side from the parent process before, *during* and after the child process: FYI, I'm sticking with the test case that I first posted several days ago and which has been cruelly ignored ever since. I've been slowly modifying it for the last several days. I think I'm seeing some pattern to the way Linux handles this and I should be able to make Cygwin work the same way. This seems to be fixed in the latest snapshot, as far as emacs is concerned. I no longer see any difference between Cygwin and Linux there. I also get the expected results when I run the test cases that Andy posted. But when I run the original test case that you posted in http://cygwin.com/ml/cygwin/2010-10/msg00395.html I'm getting strange behavior. I ran it with no argument, getting 0 = tcgetpgrp(4) 0 = ioctl(fd, TIOCGPGRP, pid), pid = 0 but then the terminal seemed to hang, and I didn't get a new prompt. I tried this both in mintty and xterm. I think this falls nicely into the cruelly ignored comment above since I can get my test case to hang on a Windows 7 system prior to the inclusion of any of my recent patches. I'll fix it though. 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
Re: Sending signals to a subprocess
On Sun, Oct 24, 2010 at 12:40:51PM -0400, Christopher Faylor wrote: I'll fix it though. The problem should be fixed in the snapshot that is currently being built. It will show up at cygwin.com soon. 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
Re: Sending signals to a subprocess
On 10/24/2010 2:55 PM, Christopher Faylor wrote: On Sun, Oct 24, 2010 at 12:40:51PM -0400, Christopher Faylor wrote: I'll fix it though. The problem should be fixed in the snapshot that is currently being built. Confirmed. Thanks. Ken -- 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
Re: Sending signals to a subprocess
On 10/20/2010 4:32 PM, Christopher Faylor wrote: On Wed, Oct 20, 2010 at 08:25:37PM +0100, Andy Koppe wrote: On 20 October 2010 13:20, Andy Koppe wrote: Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she saw Linux doing that. ??But when I run Corinna's test on my Linux system, I get -1 where she got 0. ??So not all Linuxes agree on what tcgetpgrp should do. Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before the child is forked and after it exited, so it's correct to report that there's no foreground process. I wonder which Linux it was that returned 0 in case of failure. I've tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and also a Debian with a 2.4 kernel, and got -1 on all of those. Actually I'd only tried my test on all three systems, whereas I'd tried Corinna's only on the old Redhat, where it did print -1 for failure. On the 2.4 system it can't open /dev/ptmx, whereas on the Opensuse with 2.6.34 I do get the results Corinna reported, including 0 on the master side of the pty when enquiring from the parent. (Process 0 is the startup process, so I guess that makes some sense.) To bring my ramblings to some sort of conclusion, here's a slightly amended version of Corinna's test that checks the master side from the parent process before, *during* and after the child process: FYI, I'm sticking with the test case that I first posted several days ago and which has been cruelly ignored ever since. I've been slowly modifying it for the last several days. I think I'm seeing some pattern to the way Linux handles this and I should be able to make Cygwin work the same way. This seems to be fixed in the latest snapshot, as far as emacs is concerned. I no longer see any difference between Cygwin and Linux there. I also get the expected results when I run the test cases that Andy posted. But when I run the original test case that you posted in http://cygwin.com/ml/cygwin/2010-10/msg00395.html I'm getting strange behavior. I ran it with no argument, getting 0 = tcgetpgrp(4) 0 = ioctl(fd, TIOCGPGRP, pid), pid = 0 but then the terminal seemed to hang, and I didn't get a new prompt. I tried this both in mintty and xterm. Ken -- 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
Re: Sending signals to a subprocess
On 10/20/2010 1:09 AM, Andy Koppe wrote:
On 20 October 2010 04:17, Ken Brownkbr...@cornell.edu wrote:
Emacs creates a subprocess that runs an interactive bash shell. Emacs wants
to get the PGID of the foreground process group associated to the tty of
this shell, and it does this on Linux via TIOCGPGRP (or equally well
tcgetpgrp). I think it uses the file descriptor of the master of the pty
for this purpose. If you (or some other programmer reading this) could give
me the code for setting all this up, I could play with it and try to figure
out why I'm seeing a difference between Linux and Cygwin here. I just don't
know how to create a subprocess, give it a terminal, etc.
Here's a test along those lines that does show a difference between
Linux and Cygwin:
#includestdio.h
#includepty.h
int main(void)
{
int pid, fd;
pid = forkpty(fd, 0, 0, 0);
if (!pid)
sleep(2);
else {
sleep(1);
printf(pid=%i fd=%i pgrp=%i\n, pid, fd, tcgetpgrp(fd));
}
}
Thanks, Andy. I had no idea how to do this.
On Linux, where it requires -lutil to link, this gives:
pid=13308 fd=3 tcgetpgrp(fd)=13308
I can confirm this on my Linux system. I mention this because
apparently tcgetpgrp isn't the same on all Linux systems. See below.
On Cygwin:
pid=268 fd=3 tcgetpgrp(fd)=0
Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because
she saw Linux doing that. But when I run Corinna's test on my Linux
system, I get -1 where she got 0. So not all Linuxes agree on what
tcgetpgrp should do.
Neither of those looks POSIX-compliant to me, because tcgetpgrp should
return -1 since fd 3 isn't the controlling terminal of the calling
process, but the Linux behaviour is rather useful. Perhaps they
decided to apply that restriction only to the slave side?
Ken
--
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
Re: Sending signals to a subprocess
On 20 October 2010 12:21, Ken Brown wrote:
On 10/20/2010 1:09 AM, Andy Koppe wrote:
Emacs creates a subprocess that runs an interactive bash shell. Emacs
wants
to get the PGID of the foreground process group associated to the tty of
this shell, and it does this on Linux via TIOCGPGRP (or equally well
tcgetpgrp). I think it uses the file descriptor of the master of the pty
for this purpose. If you (or some other programmer reading this) could
give
me the code for setting all this up, I could play with it and try to
figure
out why I'm seeing a difference between Linux and Cygwin here. I just
don't
know how to create a subprocess, give it a terminal, etc.
Here's a test along those lines that does show a difference between
Linux and Cygwin:
#includestdio.h
#includepty.h
int main(void)
{
int pid, fd;
pid = forkpty(fd, 0, 0, 0);
if (!pid)
sleep(2);
else {
sleep(1);
printf(pid=%i fd=%i pgrp=%i\n, pid, fd, tcgetpgrp(fd));
}
}
Thanks, Andy. I had no idea how to do this.
D'oh, I'd actually written a very similar test before, except there
I'd looked at the slave side of the pty only:
http://www.cygwin.com/ml/cygwin-developers/2009-10/msg00101.html
So here's a test trying tcgetpgrp on both sides:
#include stdlib.h
#include stdio.h
#include unistd.h
#include pty.h
int main(void) {
int pid, master_fd, slave_fd;
openpty(master_fd, slave_fd, 0, 0, 0);
pid = fork();
if (!pid) {
close(master_fd);
login_tty(slave_fd);
sleep(2);
}
else {
sleep(1);
printf(pid=%i tcgetpgrp(master_fd)=%i tcgetpgrp(slave_fd)=%i\n,
pid, tcgetpgrp(master_fd), tcgetpgrp(slave_fd));
}
}
Cygwin 1.5:
pid=1072 tcgetpgrp(master_fd)=1072 tcgetpgrp(slave_fd)=1072
Cygwin 1.7:
pid=2440 tcgetpgrp(master_fd)=0 tcgetpgrp(slave_fd)=-1
Linux:
pid=23238 tcgetpgrp(master_fd)=23238 tcgetpgrp(slave_fd)=-1
I think the luit/tcsh problem that triggered the change from 1.5 to
1.7 only concerned the slave side.
On Linux, where it requires -lutil to link, this gives:
pid=13308 fd=3 tcgetpgrp(fd)=13308
I can confirm this on my Linux system. I mention this because apparently
tcgetpgrp isn't the same on all Linux systems. See below.
On Cygwin:
pid=268 fd=3 tcgetpgrp(fd)=0
Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she
saw Linux doing that. But when I run Corinna's test on my Linux system, I
get -1 where she got 0. So not all Linuxes agree on what tcgetpgrp should
do.
Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before
the child is forked and after it exited, so it's correct to report
that there's no foreground process.
I wonder which Linux it was that returned 0 in case of failure. I've
tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and
also a Debian with a 2.4 kernel, and got -1 on all of those.
Andy
--
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
Re: Sending signals to a subprocess
On 20 October 2010 13:20, Andy Koppe wrote:
Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she
saw Linux doing that. But when I run Corinna's test on my Linux system, I
get -1 where she got 0. So not all Linuxes agree on what tcgetpgrp should
do.
Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before
the child is forked and after it exited, so it's correct to report
that there's no foreground process.
I wonder which Linux it was that returned 0 in case of failure. I've
tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and
also a Debian with a 2.4 kernel, and got -1 on all of those.
Actually I'd only tried my test on all three systems, whereas I'd
tried Corinna's only on the old Redhat, where it did print -1 for
failure. On the 2.4 system it can't open /dev/ptmx, whereas on the
Opensuse with 2.6.34 I do get the results Corinna reported, including
0 on the master side of the pty when enquiring from the parent.
(Process 0 is the startup process, so I guess that makes some sense.)
To bring my ramblings to some sort of conclusion, here's a slightly
amended version of Corinna's test that checks the master side from the
parent process before, *during* and after the child process:
#define _XOPEN_SOURCE
#include stdio.h
#include stdlib.h
#include string.h
#include errno.h
#include sys/fcntl.h
#include sys/wait.h
#include unistd.h
#include termios.h
#include sys/ioctl.h
int main ()
{
int master, slave, status;
char pts[256];
printf (parent pid: %d\n, getpid ());
if ((master = open (/dev/ptmx, O_RDWR | O_NOCTTY)) = 0)
{
int ret;
grantpt (master);
unlockpt (master);
printf (parent tcgetpgrp master before child: %d\n, tcgetpgrp (master));
strcpy (pts, ptsname (master));
switch (fork ())
{
case -1:
break;
case 0: // child
ret = setsid ();
printf (child pid: %d (setsid: %d)\n, getpid (), ret);
printf (child tcgetpgrp master before open: %d\n,
tcgetpgrp(master));
if ((slave = open (pts, O_RDWR)) = 0)
{
printf (child tcgetpgrp master after open: %d\n,
tcgetpgrp (master));
printf (child tcgetpgrp slave: %d\n, tcgetpgrp (slave));
close (slave);
}
sleep(2);
break;
default:// parent
sleep(1);
printf (parent tcgetpgrp master during child: %d\n,
tcgetpgrp (master));
wait (status);
printf (parent tcgetpgrp master after child: %d\n,
tcgetpgrp (master));
break;
}
close (master);
return 0;
}
return 1;
}
On Cygwin 1.7:
parent pid: 5000
parent tcgetpgrp master before child: 0
child pid: 1572 (setsid: 1572)
child tcgetpgrp master before open: 0
child tcgetpgrp master after open: 1572
child tcgetpgrp slave: 1572
parent tcgetpgrp master during child: 0
parent tcgetpgrp master after child: 0
On Opensuse with 2.6.34 kernel:
parent pid: 13507
parent tcgetpgrp master before child: 0
child pid: 13508 (setsid: 13508)
child tcgetpgrp master before open: 0
child tcgetpgrp master after open: 13508
child tcgetpgrp slave: 13508
parent tcgetpgrp master during child: 13508
parent tcgetpgrp master after child: 0
Andy
--
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
Re: Sending signals to a subprocess
On Wed, Oct 20, 2010 at 08:25:37PM +0100, Andy Koppe wrote: On 20 October 2010 13:20, Andy Koppe wrote: Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she saw Linux doing that. ??But when I run Corinna's test on my Linux system, I get -1 where she got 0. ??So not all Linuxes agree on what tcgetpgrp should do. Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before the child is forked and after it exited, so it's correct to report that there's no foreground process. I wonder which Linux it was that returned 0 in case of failure. I've tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and also a Debian with a 2.4 kernel, and got -1 on all of those. Actually I'd only tried my test on all three systems, whereas I'd tried Corinna's only on the old Redhat, where it did print -1 for failure. On the 2.4 system it can't open /dev/ptmx, whereas on the Opensuse with 2.6.34 I do get the results Corinna reported, including 0 on the master side of the pty when enquiring from the parent. (Process 0 is the startup process, so I guess that makes some sense.) To bring my ramblings to some sort of conclusion, here's a slightly amended version of Corinna's test that checks the master side from the parent process before, *during* and after the child process: FYI, I'm sticking with the test case that I first posted several days ago and which has been cruelly ignored ever since. I've been slowly modifying it for the last several days. I think I'm seeing some pattern to the way Linux handles this and I should be able to make Cygwin work the same way. Just in case it isn't clear, this all has nothing, AFAICT, to do with the fact that Cygwin doesn't implement TIO[CS]PGRP but I have implemented those two ioctl's nonetheless. 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
Re: Sending signals to a subprocess
On 10/20/2010 4:32 PM, Christopher Faylor wrote: On Wed, Oct 20, 2010 at 08:25:37PM +0100, Andy Koppe wrote: On 20 October 2010 13:20, Andy Koppe wrote: Corinna made tcgetpgrp return 0 instead of -1 in some circumstances (see http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html) because she saw Linux doing that. ??But when I run Corinna's test on my Linux system, I get -1 where she got 0. ??So not all Linuxes agree on what tcgetpgrp should do. Hmm, Corinna's test calls tcgetpgrp(master) in the parent only before the child is forked and after it exited, so it's correct to report that there's no foreground process. I wonder which Linux it was that returned 0 in case of failure. I've tried it on a recent Opensuse, an old Redhat with a 2.6.9 kernel, and also a Debian with a 2.4 kernel, and got -1 on all of those. Actually I'd only tried my test on all three systems, whereas I'd tried Corinna's only on the old Redhat, where it did print -1 for failure. On the 2.4 system it can't open /dev/ptmx, whereas on the Opensuse with 2.6.34 I do get the results Corinna reported, including 0 on the master side of the pty when enquiring from the parent. (Process 0 is the startup process, so I guess that makes some sense.) To bring my ramblings to some sort of conclusion, here's a slightly amended version of Corinna's test that checks the master side from the parent process before, *during* and after the child process: FYI, I'm sticking with the test case that I first posted several days ago and which has been cruelly ignored ever since. I've been slowly modifying it for the last several days. I didn't ignore it. I just didn't know how to modify it to deal with subprocesses, which was the situation I was trying to understand. I think I'm seeing some pattern to the way Linux handles this and I should be able to make Cygwin work the same way. That would be great. Thanks. Just in case it isn't clear, this all has nothing, AFAICT, to do with the fact that Cygwin doesn't implement TIO[CS]PGRP but I have implemented those two ioctl's nonetheless. It's clear, and I agree. Ken -- 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
Re: Sending signals to a subprocess
On 10/18/2010 4:18 PM, Christopher Faylor wrote:
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page. A simple test case
(tm) seems to bear out the fact that the two are the same.
I just tried an experiment, and now I'm thoroughly confused. I inserted
#undef TIOCGPGRP into process.c in the emacs source and rebuilt it on
Linux. [Technical note if anyone wants to try to reproduce this: I also
inserted #undef SIGNALS_VIA_CHARACTERS, since SIGNALS_VIA_CHARACTERS
provides an alternate method of sending signals to processes; this is in
fact my workaround on Cygwin.] Then trying to kill a process running in
an emacs shell with C-c C-c fails the same way it fails in Cygwin. So
somehow TIOCGPGRP is doing the right thing under Linux in the emacs code
above, in spite of its limitations. I don't understand why. When I get
a chance (not today), I'll try running emacs under gdb to see if I can
figure out what's going on.
I guess this should mean that if you implement TIOCGPGRP in Cygwin and
make it emulate Linux, it should work for emacs in Cygwin too. I can
also try to see if tcgetpgrp works instead of TIOCGPGRP. I'm
embarrassed to say that I didn't actually try this before, because my
understanding of the documentation was that it wouldn't work. You can
see I don't think like a programmer.
Ken
--
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
Re: Sending signals to a subprocess
On Tue, Oct 19, 2010 at 09:32:34AM -0400, Ken Brown wrote:
On 10/18/2010 4:18 PM, Christopher Faylor wrote:
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1! NILP
(p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group
on this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page. A simple test case
(tm) seems to bear out the fact that the two are the same.
I just tried an experiment, and now I'm thoroughly confused. I inserted
#undef TIOCGPGRP into process.c in the emacs source and rebuilt it on
Linux. [Technical note if anyone wants to try to reproduce this: I also
inserted #undef SIGNALS_VIA_CHARACTERS, since SIGNALS_VIA_CHARACTERS
provides an alternate method of sending signals to processes; this is in
fact my workaround on Cygwin.] Then trying to kill a process running in
an emacs shell with C-c C-c fails the same way it fails in Cygwin. So
somehow TIOCGPGRP is doing the right thing under Linux in the emacs code
above, in spite of its limitations. I don't understand why. When I get
a chance (not today), I'll try running emacs under gdb to see if I can
figure out what's going on.
I guess this should mean that if you implement TIOCGPGRP in Cygwin and
make it emulate Linux, it should work for emacs in Cygwin too. I can
also try to see if tcgetpgrp works instead of TIOCGPGRP. I'm
embarrassed to say that I didn't actually try this before, because my
understanding of the documentation was that it wouldn't work. You can
see I don't think like a programmer.
As I mentioned, my test case shows that when run on Linux, TIOCPGRP and
tcgetpgrp are the same. So, given that, if I implemented TIOCPGRP it
wouldn't solve your problem.
How about if you modify the test case that I provided and show me what's
different? Is this an issue with opening the wrong side of a pty, like
trying to run tcgetpgrp on the master rather than the slave or vice versa?
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
Re: Sending signals to a subprocess
On 10/19/2010 10:15 AM, Christopher Faylor wrote:
On Tue, Oct 19, 2010 at 09:32:34AM -0400, Ken Brown wrote:
On 10/18/2010 4:18 PM, Christopher Faylor wrote:
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page. A simple test case
(tm) seems to bear out the fact that the two are the same.
I just tried an experiment, and now I'm thoroughly confused. I inserted
#undef TIOCGPGRP into process.c in the emacs source and rebuilt it on
Linux. [Technical note if anyone wants to try to reproduce this: I also
inserted #undef SIGNALS_VIA_CHARACTERS, since SIGNALS_VIA_CHARACTERS
provides an alternate method of sending signals to processes; this is in
fact my workaround on Cygwin.] Then trying to kill a process running in
an emacs shell with C-c C-c fails the same way it fails in Cygwin. So
somehow TIOCGPGRP is doing the right thing under Linux in the emacs code
above, in spite of its limitations. I don't understand why. When I get
a chance (not today), I'll try running emacs under gdb to see if I can
figure out what's going on.
I guess this should mean that if you implement TIOCGPGRP in Cygwin and
make it emulate Linux, it should work for emacs in Cygwin too. I can
also try to see if tcgetpgrp works instead of TIOCGPGRP. I'm
embarrassed to say that I didn't actually try this before, because my
understanding of the documentation was that it wouldn't work. You can
see I don't think like a programmer.
As I mentioned, my test case shows that when run on Linux, TIOCPGRP and
tcgetpgrp are the same. So, given that, if I implemented TIOCPGRP it
wouldn't solve your problem.
You're right. I'm convinced now that TIOCGPGRP and tcgetpgrp are the
same on Linux, so implementing TIOCGPGRP would not help me. To
double-check, I rewrote the emacs code to use tcgetpgrp instead of
TIOCGPGRP, and it worked on Linux just as well as before. But the same
code fails on Cygwin. I don't understand why it works on Linux, because
it appears to me to be using tcgetpgrp in the situation where it's
supposed to fail
I would like to create a STC that would let me investigate this further,
but I don't know enough programming to do it. It ought to be completely
trivial.
Re: Sending signals to a subprocess
On Tue, Oct 19, 2010 at 11:17:39PM -0400, Ken Brown wrote: On 10/19/2010 10:15 AM, Christopher Faylor wrote: I would like to create a STC that would let me investigate this further, but I don't know enough programming to do it. It ought to be completely trivial. Here's what happens: Emacs creates a subprocess that runs an interactive bash shell. Emacs wants to get the PGID of the foreground process group associated to the tty of this shell, and it does this on Linux via TIOCGPGRP (or equally well tcgetpgrp). I think it uses the file descriptor of the master of the pty for this purpose. If you (or some other programmer reading this) could give me the code for setting all this up, I could play with it and try to figure out why I'm seeing a difference between Linux and Cygwin here. I just don't know how to create a subprocess, give it a terminal, etc. I provided a simple text case here: http://cygwin.com/ml/cygwin/2010-10/msg00395.html 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
Re: Sending signals to a subprocess
On 20 October 2010 04:17, Ken Brown kbr...@cornell.edu wrote:
Emacs creates a subprocess that runs an interactive bash shell. Emacs wants
to get the PGID of the foreground process group associated to the tty of
this shell, and it does this on Linux via TIOCGPGRP (or equally well
tcgetpgrp). I think it uses the file descriptor of the master of the pty
for this purpose. If you (or some other programmer reading this) could give
me the code for setting all this up, I could play with it and try to figure
out why I'm seeing a difference between Linux and Cygwin here. I just don't
know how to create a subprocess, give it a terminal, etc.
Here's a test along those lines that does show a difference between
Linux and Cygwin:
#include stdio.h
#include pty.h
int main(void)
{
int pid, fd;
pid = forkpty(fd, 0, 0, 0);
if (!pid)
sleep(2);
else {
sleep(1);
printf(pid=%i fd=%i pgrp=%i\n, pid, fd, tcgetpgrp(fd));
}
}
On Linux, where it requires -lutil to link, this gives:
pid=13308 fd=3 tcgetpgrp(fd)=13308
On Cygwin:
pid=268 fd=3 tcgetpgrp(fd)=0
Neither of those looks POSIX-compliant to me, because tcgetpgrp should
return -1 since fd 3 isn't the controlling terminal of the calling
process, but the Linux behaviour is rather useful. Perhaps they
decided to apply that restriction only to the slave side?
Andy
--
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
Re: Sending signals to a subprocess
On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). But while :; do echo +; sleep 1; done can be broken by C-c C-c. Also 'yes' can be broken by C-c C-\ (QUIT). -- 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
Re: Sending signals to a subprocess
On 10/18/2010 4:46 AM, Oleksandr Gavenko wrote: On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). Yes, this is a known problem with native emacs and is documented in etc/PROBLEMS. But Cygwin emacs will no longer have this problem as of Emacs 23.3. Ken -- 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
Re: Sending signals to a subprocess
On 18.10.2010 15:36, Ken Brown wrote: On 10/18/2010 4:46 AM, Oleksandr Gavenko wrote: On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). Yes, this is a known problem with native emacs and is documented in etc/PROBLEMS. But Cygwin emacs will no longer have this problem as of Emacs 23.3. Did you mean ** Interrupting Cygwin port of Bash from Emacs doesn't work. Cygwin 1.x builds of the ported Bash cannot be interrupted from the MS-Windows version of Emacs. This is due to some change in the Bash port or in the Cygwin library which apparently make Bash ignore the keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports of Bash, up to b20.1, did receive SIGINT from Emacs.) -- 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
Re: Sending signals to a subprocess
On 10/18/2010 9:12 AM, Oleksandr Gavenko wrote: On 18.10.2010 15:36, Ken Brown wrote: On 10/18/2010 4:46 AM, Oleksandr Gavenko wrote: On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). Yes, this is a known problem with native emacs and is documented in etc/PROBLEMS. But Cygwin emacs will no longer have this problem as of Emacs 23.3. Did you mean ** Interrupting Cygwin port of Bash from Emacs doesn't work. Cygwin 1.x builds of the ported Bash cannot be interrupted from the MS-Windows version of Emacs. This is due to some change in the Bash port or in the Cygwin library which apparently make Bash ignore the keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports of Bash, up to b20.1, did receive SIGINT from Emacs.) Yes. But let's not discuss native emacs further. It's off topic for the cygwin list and also for this thread. -- 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
Re: Sending signals to a subprocess
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. 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
Re: Sending signals to a subprocess
On 10/18/2010 10:58 AM, Christopher Faylor wrote: On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. Yes, that would be great. Thanks. Ken -- 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
Re: Sending signals to a subprocess
On 18 October 2010 18:27, Ken Brown wrote: On 10/18/2010 10:58 AM, Christopher Faylor wrote: On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. Yes, that would be great. Thanks. I'd put that to use in mintty too, to improve support for relative paths when opening a file with Ctrl+click or the 'Open' menu command. Andy -- 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
Re: Sending signals to a subprocess
On Mon, Oct 18, 2010 at 06:40:19PM +0100, Andy Koppe wrote: On 18 October 2010 18:27, Ken Brown wrote: On 10/18/2010 10:58 AM, Christopher Faylor wrote: On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. ??A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. ??I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. ??But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. Yes, that would be great. ??Thanks. I'd put that to use in mintty too, to improve support for relative paths when opening a file with Ctrl+click or the 'Open' menu command. Ok, that's even more incentive for me to do this. It's been on my todo list for years. I'll try to get to it soon. (But now that I said this, I'll probably soon discover why it hasn't been implemented already) 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
Re: Sending signals to a subprocess
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on this
terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
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
Re: Sending signals to a subprocess
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on this
terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Ken
--
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
Re: Sending signals to a subprocess
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page. A simple test case
(tm) seems to bear out the fact that the two are the same.
If you compile/link the below on linux and provide, e.g., /dev/tty0 as
an argument, then the command fails, even when run as root. If you give
it no argument or give it the fd of the current controlling tty then
both tcgetpgrp and TIOCGPGRP both succeed.
cgf
#include termios.h
#include sys/fcntl.h
#include stdio.h
#include string.h
#include errno.h
#include sys/ioctl.h
#include unistd.h
#include stdlib.h
int
main (int argc, char **argv)
{
int res;
pid_t pid;
const char tty[100];
int fd;
if (argc == 1)
{
int fds;
res = openpty (fd, fds, tty, NULL, NULL);
if (fd 0)
{
fprintf (stderr, openpty failed: %s\n, strerror (errno));
exit (1);
}
}
else
{
fd = open (argv[1], O_RDONLY);
if (fd 0)
{
fprintf (stderr, open failed: %s\n, strerror (errno));
exit (1);
}
}
printf (%d = tcgetpgrp(%d), res = tcgetpgrp (fd), fd);
if (res 0)
printf ( - %s, strerror (errno));
puts ();
printf (%d = ioctl(fd, TIOCGPGRP, pid), res = ioctl(fd, TIOCGPGRP, pid));
if (res 0)
printf ( - %s, strerror (errno));
else
printf (, pid = %d, pid);
puts ();
exit (0);
}
--
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
Re: Sending signals to a subprocess
On 10/18/2010 4:18 PM, Christopher Faylor wrote:
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page.
Sorry, I missed the point. In view of the use of TIOCGPGRP in emacs,
there must be some unix-like systems (BSD?) where TIOCGPGRP is not
subject to that limitation. Is it necessary to keep the limitation in
Cygwin? I guess it boils down to how important Linux compatibility is,
given that POSIX (as far as I know) is silent about TIOCGPGRP.
This is not a big deal from my point of view. As I said in my first
message, I have a workaround for the most important uses in emacs. I
think it might be more of an issue for mintty.
Ken
--
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
Re: Sending signals to a subprocess
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
Ken
--
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
