Mail Archives: cygwin/2001/05/08/16:30:49
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
- Raw text -