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

[Troy Noble <troy dot noble at channelpoint dot com>]

Thanks for your patience.

I tried the latest patch you checked in for exceptions.cc.
That didn't do it either.  I have another alternative though.

I'm beginning to regret the "brainstorming" in the subject of this
thread, as I'm now feeling somewhat stumped and stupid.  I've fixed
it 4 different ways now, but haven't quite hit on the right one.
Sorry for being dense.

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?  The problem is that stdio_init gets called all the
time when
a process starts, and since ctty<0 and GetConsoleCP() is always
going to return > 0, my ctty and tty->pgid always get set.

I don't think you'd want to run this except when you were creating actual
fhandler_console instances, right?  The build_fhandler already has code to
detect if it's dealing with a pipe or a console-type device, and constructs
the appropriate fhandler_pipe or fhandler_console accordingly.  So that
might be the best way to trigger the behavior I need.

So I tried moving this code:

    if (myself->ctty < 0 && GetConsoleCP () > 0)
        set_console_ctty ();

into the fhandler_console::init() method, and voila it worked equally
well for me as the other patch I sent earlier.  PATCH IS INCLUDED
BELOW.

Note that I _DO NOT_ put "tty" in my CYGWIN variable, because it prevents
me shutting down other non-cygwin processes with CTRL-C (even with
your latest exceptions.cc patch.  I tried it).  The reason is that the
ctrl_c_handler never gets invoked when CYGWIN=tty as far as I can tell.

I think you are right though, GetConsoleCP always returns > 0
for a child process running in a FSF NTEmacs shell buffer.
NTEmacs creates that console itself.  This is consistent with
what Andrew Innes said in:

    http://sources.redhat.com/ml/cygwin/2001-01/msg00928.html

   "It [NTEmacs] temporarily gives input focus to the (still hidden)
    console window for that subprocess, simulates the user typing
    Ctrl-C (or Ctrl-Break in some versions), then switches focus back
    to Emacs."


So here is my 5th attempt at a patch.  I tested it with/without
CYGWIN=tty in a console window, as well as without the "tty"
in an NTEmacs shell buffer.  Works well in all cases (recall that
I mentioned in prior mail, CYGWIN=tty doesn't work well in an Emacs
shell buffer.)


% cvs diff --unified=3 src/winsup/cygwin/dtable.cc
Index: src/winsup/cygwin/dtable.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/dtable.cc,v
retrieving revision 1.37
diff --unified=3 -r1.37 dtable.cc
--- dtable.cc   2001/04/28 23:48:27     1.37
+++ dtable.cc   2001/05/08 18:31:35
@@ -87,7 +87,6 @@
 void
 stdio_init (void)
 {
-  extern void set_console_ctty ();
   /* Set these before trying to output anything from strace.
      Also, always set them even if we're to pick up our parent's fds
      in case they're missed.  */
@@ -118,10 +117,6 @@

       cygheap->fdtab.init_std_file_from_handle (1, out, GENERIC_WRITE,
"{stdout}");
       cygheap->fdtab.init_std_file_from_handle (2, err, GENERIC_WRITE,
"{stderr}");
-      /* Assign the console as the controlling tty for this process if we
actually
-        have a console and no other controlling tty has been assigned. */
-      if (myself->ctty < 0 && GetConsoleCP () > 0)
-       set_console_ctty ();
     }
 }

% cvs diff --unified=3 src/winsup/cygwin/fhandler_console.cc
Index: src/winsup/cygwin/fhandler_console.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_console.cc,v
retrieving revision 1.49
diff --unified=3 -r1.49 fhandler_console.cc
--- fhandler_console.cc 2001/04/28 23:48:27     1.49
+++ fhandler_console.cc 2001/05/08 18:32:15
@@ -1703,6 +1703,11 @@
   if (f != INVALID_HANDLE_VALUE)
     CloseHandle (f);   /* Reopened by open */

+  /* Assign the console as the controlling tty for this process if we
actually
+        have a console and no other controlling tty has been assigned. */
+  if (myself->ctty < 0 && GetConsoleCP () > 0)
+    set_console_ctty ();
+
   output_tcsetattr (0, &tc->ti);
 }


Troy

-----Original Message-----
From: Christopher Faylor [mailto:cgf@redhat.com]
Sent: Tuesday, May 08, 2001 10:44 AM
To: 'cygwin@cygwin.com'
Subject: Re: Brainstorming a fix for CTRL-C handling in an emacs shell
buf fer (non-TTY)


On Tue, May 08, 2001 at 09:45:49AM -0600, Troy Noble wrote:
>Christopher,
>
>Here's yet another patch (hopefully at the location of the
>root problem this time).
>
>I'd like to see if you come to the same conclusion as I did.
>
>$ diff -b --unified=3 dtable.cc-orig dtable.cc
>--- dtable.cc-orig      Sat Apr 28 17:48:27 2001
>+++ dtable.cc   Tue May  8 06:36:00 2001
>@@ -120,7 +120,7 @@
>       cygheap->fdtab.init_std_file_from_handle (2, err, GENERIC_WRITE,
>"{stderr}");
>       /* Assign the console as the controlling tty for this process if we
>actually
>         have a console and no other controlling tty has been assigned. */
>-      if (myself->ctty < 0 && GetConsoleCP () > 0)
>+      if (ISSTATE(myself,PID_USETTY) && myself->ctty < 0 && GetConsoleCP
()
>> 0)
>        set_console_ctty ();
>     }
> }
>

This can't be right.  This says "If you are trying to use real ttys and you
have a tty, use the console."  That's not what the code was trying to do.

The "GetConsoleCP ()" call is supposed to determine if there is a
console associated with the process.  Apparently there is, for some
reason.  Apparently, the process which started Xemacs has or had a
cygwin pid associated with it so there is a process group associated
with the tty.

I checked in a patch to in ctrl_c_handler to avoid just returning if the
cygwin pid associated with the pgid of the console is dead.

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