Mail Archives: cygwin/2010/10/20/08:21:11
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-SWARE-Spam-Status: | No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL
|
X-Spam-Check-By: | sourceware.org
|
MIME-Version: | 1.0
|
In-Reply-To: | <4CBED0C3.6080001@cornell.edu>
|
References: | <4CB9DE15 DOT 8010308 AT cornell DOT edu> <4CB9E9C0 DOT 3000509 AT cornell DOT edu> <20101018183438 DOT GA25878 AT ednor DOT casa DOT cgf DOT cx> <4CBCA2A5 DOT 4010601 AT cornell DOT edu> <20101018201805 DOT GA26254 AT ednor DOT casa DOT cgf DOT cx> <4CBD9DF2 DOT 3090804 AT cornell DOT edu> <20101019141557 DOT GA31784 AT ednor DOT casa DOT cgf DOT cx> <4CBE5F53 DOT 30402 AT cornell DOT edu> <AANLkTikUc9i0h-g3QHGzqKKRGoJf0-xSPgu6wy1U+zZ=@mail.gmail.com> <4CBED0C3 DOT 6080001 AT cornell DOT edu>
|
Date: | Wed, 20 Oct 2010 13:20:53 +0100
|
Message-ID: | <AANLkTinoRNBvUpiCGpVWXKLh4kYtyF=USrVhSuOX7_18@mail.gmail.com>
|
Subject: | Re: Sending signals to a subprocess
|
From: | Andy Koppe <andy DOT koppe AT gmail DOT com>
|
To: | cygwin AT cygwin DOT com
|
X-IsSubscribed: | yes
|
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
List-Id: | <cygwin.cygwin.com>
|
List-Unsubscribe: | <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
|
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
List-Archive: | <http://sourceware.org/ml/cygwin/>
|
List-Post: | <mailto:cygwin AT cygwin DOT com>
|
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
Sender: | cygwin-owner AT cygwin DOT com
|
Mail-Followup-To: | cygwin AT cygwin DOT com
|
Delivered-To: | mailing list cygwin AT cygwin DOT com
|
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. =C2=A0E=
macs
>>> 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). =C2=A0I think it uses the file descriptor of the master of =
the pty
>>> for this purpose. =C2=A0If 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. =C2=A0I =
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)
>> {
>> =C2=A0 int pid, fd;
>> =C2=A0 pid =3D forkpty(&fd, 0, 0, 0);
>> =C2=A0 if (!pid)
>> =C2=A0 =C2=A0 sleep(2);
>> =C2=A0 else {
>> =C2=A0 =C2=A0 sleep(1);
>> =C2=A0 =C2=A0 printf("pid=3D%i fd=3D%i pgrp=3D%i\n", pid, fd, tcgetpgrp(=
fd));
>> =C2=A0 }
>> }
>
> Thanks, Andy. =C2=A0I 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 =3D fork();
if (!pid) {
close(master_fd);
login_tty(slave_fd);
sleep(2);
}
else {
sleep(1);
printf("pid=3D%i tcgetpgrp(master_fd)=3D%i tcgetpgrp(slave_fd)=3D%i\n",
pid, tcgetpgrp(master_fd), tcgetpgrp(slave_fd));
}
}
Cygwin 1.5:
pid=3D1072 tcgetpgrp(master_fd)=3D1072 tcgetpgrp(slave_fd)=3D1072
Cygwin 1.7:
pid=3D2440 tcgetpgrp(master_fd)=3D0 tcgetpgrp(slave_fd)=3D-1
Linux:
pid=3D23238 tcgetpgrp(master_fd)=3D23238 tcgetpgrp(slave_fd)=3D-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=3D13308 fd=3D3 tcgetpgrp(fd)=3D13308
>
> I can confirm this on my Linux system. =C2=A0I mention this because appar=
ently
> tcgetpgrp isn't the same on all Linux systems. =C2=A0See below.
>
>> On Cygwin:
>>
>> pid=3D268 fd=3D3 tcgetpgrp(fd)=3D0
>
> 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. =C2=A0But when I run Corinna's test on my Linux sys=
tem, I
> get -1 where she got 0. =C2=A0So 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
- Raw text -