Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Tue, 8 May 2001 16:28:05 -0400 From: Christopher Faylor To: "'cygwin AT cygwin DOT com'" Subject: Re: Brainstorming a fix for CTRL-C handling in an emacs shell buf fer (non-TTY) Message-ID: <20010508162805.B26609@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: "'cygwin AT cygwin DOT com'" References: <8F23E55D511AD5119A6800D0B76FDDE11E1026 AT cpex3 DOT channelpoint DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <8F23E55D511AD5119A6800D0B76FDDE11E1026@cpex3.channelpoint.com>; from troy.noble@channelpoint.com on Tue, May 08, 2001 at 01:57:59PM -0600 On Tue, May 08, 2001 at 01:57:59PM -0600, Troy Noble wrote: >> >Maybe this code that calls set_console_ctty needs to be moved out >> >of dtable.cc:stdio_init and into the constructor or init method of >> >the fhandler_console? > >> It's already in the open method for any tty device. > >A grep of the code in winsup/cygwin says that set_console_ctty is >only getting called in one place, and that's in dtable.cc:stdio_init. > > .../winsup/cygwin$ grep -n set_console_ctty *.cc > dtable.cc:90: extern void set_console_ctty (); > dtable.cc:124: set_console_ctty (); > fhandler_console.cc:117:set_console_ctty () > >So maybe just need to remove it from stdio_init and move it to >the open method for the tty as intended? But if I don't re-add it >to fhandler_console::init (or somewhere in the console setup >code) I get undesirable behavior as you can imagine. The "it" I was referring to was the setting of the controlling tty. set_console_ctty calls get_tty_stuff. get_tty_stuff is called early in fhandler_console::open. >> >I don't think you'd want to run this except when you were creating actual >> >fhandler_console instances, right? > >> A program should have a controlling tty even if it doesn't have a handle open >> to the tty. That means that you can't wait until you initialize a console >> or a tty before seting the process's controlling tty. > >I thought all of the (non-console) piped processes would share "nada"? >That seems to be the intent of tty_list::get_tty(). No. nada is intended for cases where there is no console device as in when a program is invoked from a pure Windows application or when it is running in a service. In this case, the terminal should not have any controlling tty. >> So, I guess the question is, why is t->getpgid != myself->pid when >> ctrl_c_handler is invoked? What is the value of those two variabl > >Funny you should ask. Once bash has set the t->pgid, any >subsequent child processes never seem to set t->pgid. So >the only process that thinks t->getpgid == myself->pid is BASH, >which happily ignores the SIGINT. The child processes always >exit the handler prematurely because they all perceive that >t->getpgid != myself->pid Are you using a Cygwin version of bash? Why is it ignoring SIGINT? ctrl_c_handler in bash should be sending CTRL-Cs to its children. >Here's the data I've been looking at. I added the aforementioned >printf in ctrl_c_handler in the section of code we are looking at. >Again, running WITHOUT "tty" in my CYGWIN variable. > >WHEN RUNNING IN AN EMACS BUFFER: > GetConsoleCP=437 isatty=0 pid_exists=1 t->getpgid()=1552 > myself->pid=1764 pgid=1520 ppid=1520 > progname=c:\cygwin\bin\md5sum.exe > > GetConsoleCP=437 isatty=0 pid_exists=1 t->getpgid()=1552 > myself->pid=1520 pgid=1520 ppid=1552 > progname=c:\cygwin\bin\find.exe > >*> GetConsoleCP=437 isatty=0 pid_exists=1 t->getpgid()=1552 >*> myself->pid=1552 pgid=1552 ppid=1 >| progname=c:\cygwin\bin\bash.exe >| >|-- BASH still thinks its controlling the tty So, because bash thinks it is not running in a tty, it is not setting the terminal pgid of the children. I have to think about this. It may not be fixable other than the original suggestion of using a cygwin aware version of Xemacs. cgf -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple