Mail Archives: cygwin/2001/05/08/17:06:27
> 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 see what you're saying now. I find it curious that set_console_ctty
calls get_tty_stuff with no argument, so the flags are 0. Can that be good?
In particular, the call to
shared_console_info->set_ctty (TTY_CONSOLE, flags);
will always have flags==0 when called from set_console_ctty, and in
tty_min::set_ctty (fhandler_termios.cc:87)
if ((myself->ctty < 0 || myself->ctty == ttynum) && !(flags & O_NOCTTY))
!(flags & O_NOCTTY) evaluates to TRUE every time.
I thought that was rather odd, but might not be the cause of my
particular problem.
> 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.
Exactly. I am using FSF NT Emacs 20.7.1, which is a native win32 GUI app.
However, the fact that it creates a console is probably what's confusing
cygwin's bash, right?
> 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.
I've tried with both: 2.05.0(5)-release and 2.04.7(2)-release
that I used cygwin's setup.exe to install.
And I have mis-spoken again. I think bash DOES send CTRL-C's to
its children, since I see each of them pop into their ctrl_c_handler.
However, since they all know t->getpgid () != myself->pid , they all
bail out of their ctrl_c_handlers prematurely and none of them
sends the SIGINT to its PGID.
That's partly why I wanted to test if isatty(0) == FALSE, then instead
check myself->pgid != myself->pid. Then at least one of the children
would figure out that it was the process group leader and send the
SIGINT to the PGID properly. I knew I couldn't rely on t->getpgid()
to tell me the right thing in the child process in other words, even
if it was the process group leader.
> >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.
I hope not. I don't want to get flamed... but I find FSF's Emacs much
more reliable than XEmacs on win32. I have tried XEmacs and had a lot
of problems with extensions such as JDE and ECB which I use daily.
So switching to a cygwin-aware XEmacs would hinder me in other non-cygwin
related ways.
cgf
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -