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> <4CBED0C3 DOT 6080001 AT cornell DOT edu> Date: Wed, 20 Oct 2010 13:20:53 +0100 Message-ID: Subject: Re: Sending signals to a subprocess From: Andy Koppe To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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 >> #include >> >> 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 #include #include #include 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