This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Brainstorming a fix for CTRL-C handling in an emacs shell buffer (non-TTY)


I just re-read my example patch a little, and thought it might be
better to instead write:


  if ((GetTickCount () - t->last_ctrl_c) < MIN_CTRL_C_SLOP ||
      (GetEnvironmentVariable("CYGWIN_HANDLE_NONTTY_CTRL_C",
                              envBuf, MAX_PATH-1)==0 &&
       (!t->getpgid () || t->getpgid () != myself->pid)))
    return TRUE;

to avoid re-introducing a bug that I presume this timing check
was added to prevent ;->

Sorry about that.  Like I said, I don't claim it's clean.

Troy

-----Original Message-----
From: Troy Noble [mailto:troy.noble@channelpoint.com]
Sent: Friday, May 04, 2001 12:41 PM
To: 'cygwin@cygwin.com'
Subject: Brainstorming a fix for CTRL-C handling in an emacs shell
buffer (non-TTY)


I have been reading through the list archives and the latest CVS 1.3.2 code
a bit today, so am pretty confident I understand most of the issues related
to CTRL-C not generating SIGINT when stdin is not a tty (like inside a
Win32 NTEmacs shell buffer).  Here's an earlier discussion on this same
subject:

   http://cygwin.com/ml/cygwin/2001-01/msg00578.html  and ff.

Would it be possible to add a new "CYGWIN=" option or environment variable
to allow one to turn on CTRL-C handling even if stdin is not a tty?

.../cygwin$ diff -b --unified=3 exceptions.cc-orig exceptions.cc
diff -b --unified=3 exceptions.cc-orig exceptions.cc
--- exceptions.cc-orig	Sun Apr 29 21:09:18 2001
+++ exceptions.cc	Fri May  4 12:10:44 2001
@@ -878,6 +878,7 @@
 static BOOL WINAPI
 ctrl_c_handler (DWORD type)
 {
+  static CHAR envBuf[MAX_PATH];
   if (type == CTRL_LOGOFF_EVENT)
     return TRUE;
 
@@ -892,8 +893,10 @@
   tty_min *t = cygwin_shared->tty.get_tty (myself->ctty);
   /* Ignore this if we're not the process group lead since it should be
handled
      *by* the process group leader. */
-  if (!t->getpgid () || t->getpgid () != myself->pid ||
-      (GetTickCount () - t->last_ctrl_c) < MIN_CTRL_C_SLOP)
+  if (GetEnvironmentVariable("CYGWIN_HANDLE_NONTTY_CTRL_C",
+                             envBuf, MAX_PATH-1)==0 &&
+      (!t->getpgid () || t->getpgid () != myself->pid ||
+       (GetTickCount () - t->last_ctrl_c) < MIN_CTRL_C_SLOP))
     return TRUE;
   else
     /* Otherwise we just send a SIGINT to the process group and return TRUE
(to indicate



I tried the above hack of the latest sources just to test my theory.  I
don't claim it's
the best way to do it, or even that it's "good" code.  I don't know enough
about
internals of CYGWIN to advocate one way or another whether it should be a
CYGWIN= or an environment variable.  But it would really be nice to have if
you can come up with a cleaner way to do it.

The only obvious side-effect I've observed thusfar is:

bash: [792: 1] tcsetattr: Not a character device

when I use CTRL-C inside emacs.  But the subprocess does get a SIGINT as I'd
like.

Outside of emacs, everything works as it always has.  For non-cygwin apps
running inside of emacs, I was still able to kill the processes as well
(Note
that I discovered a while back that I also had to NOT put "tty" in my
CYGWIN=
variable to allow me to kill non-cygwin processes... but that's possibly
another issue altogether).


P.S.  I did also read the discussion about switching to XEmacs built for
cygwin, but
would like to get it to work with native NTEmacs as well... since that's
what we use
here.  BTW, this same CTRL-C behavior did work in B20.1.  There was some
doubt about that in the prior e-mail thread.


--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]