Mail Archives: cygwin/2001/05/08/14:53:52
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 AT redhat DOT com]
Sent: Tuesday, May 08, 2001 10:44 AM
To: 'cygwin AT cygwin DOT 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
- Raw text -