Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <8F23E55D511AD5119A6800D0B76FDDE11E1029@cpex3.channelpoint.com>
From: Troy Noble <troy DOT noble AT channelpoint DOT com>
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: RE: Brainstorming a fix for CTRL-C handling in an emacs shell buf
	 fer (non-TTY)
Date: Tue, 8 May 2001 15:05:58 -0600 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> 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