Re: Brainstorming a fix for CTRL-C handling in an emacs shell buf fer (non-TTY)

[Christopher Faylor <cgf at redhat dot com>]

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