From owner-ntemacs-users@cs.washington.edu Thu Aug 7 06:42:57 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Thu" " 7" "August" "1997" "13:47:22" "+0100" "Andrew Innes" "andrewi@harlequin.co.uk" nil "51" "Re: trouble passing ^C through to processes running in a *shell*" "^From:" nil nil "8" nil nil nil nil] nil) Received: from joker.cs.washington.edu (joker.cs.washington.edu [128.95.1.42]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id GAA12717 for ; Thu, 7 Aug 1997 06:37:30 -0700 Received: from trout.cs.washington.edu (trout.cs.washington.edu [128.95.1.178]) by joker.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id GAA36467 for ; Thu, 7 Aug 1997 06:37:29 -0700 Received: (majordom@localhost) by trout.cs.washington.edu (8.8.5+CS/7.2ws+) id FAA26609 for ntemacs-users-outgoing; Thu, 7 Aug 1997 05:48:16 -0700 (PDT) Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by trout.cs.washington.edu (8.8.5+CS/7.2ws+) with ESMTP id FAA26605 for ; Thu, 7 Aug 1997 05:48:14 -0700 (PDT) Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with ESMTP id FAA10911 for ; Thu, 7 Aug 1997 05:48:07 -0700 Received: from propos.long.harlequin.co.uk (propos.long.harlequin.co.uk [193.128.93.50]) by holly.cam.harlequin.co.uk (8.8.4/8.8.4) with ESMTP id NAA10338; Thu, 7 Aug 1997 13:47:55 +0100 (BST) Received: from woozle.long.harlequin.co.uk (woozle.long.harlequin.co.uk [193.128.93.77]) by propos.long.harlequin.co.uk (8.8.4/8.6.12) with SMTP id NAA00521; Thu, 7 Aug 1997 13:47:22 +0100 (BST) Message-Id: <199708071247.NAA00521@propos.long.harlequin.co.uk> In-reply-to: <33E90B3A.FA8ED313@marimba.com> (message from Jonathan Payne on Wed, 06 Aug 1997 16:39:38 -0700) Precedence: bulk From: Andrew Innes Sender: owner-ntemacs-users@cs.washington.edu To: jpayne@marimba.com CC: rpeck@EnsembleSolutions.com, ntemacs-users@cs.washington.edu Subject: Re: trouble passing ^C through to processes running in a *shell* Date: Thu, 7 Aug 1997 13:47:22 +0100 (BST) On Wed, 06 Aug 1997 16:39:38 -0700, Jonathan Payne said: >With Java, on solaris the QUIT signal generates the stack trace you are >seeing. On NT/95, the stack trace is buffered, so you are generating >the stack trace as soon as you type ^C, but not seeing it until Java >exits and flushes all its buffers. This is a common problem with running subprocesses on Windows - there is no (defined) way for Emacs to redirect stdin/out/err for the subprocess and yet make it appear to the application that it is running in a normal command window. Most applications disable stdout buffering when stdout is the console window, but not when it is a file or pipe. On Unix, Emacs uses pseudo-tty's for precisely this purpose - to get the same thing on NT would require access to kernel structures so that Emacs could get the kernel to lie to the subprocess about the type of its standard handles. (Actually, it's technically possible to use really sneaky hacks in the subprocess' user space to achieve the same effect, at least for Win32 programs, but I'm not sure I want to go to that much trouble.) >But the real issue is that Java >didn't exit when ^C was typed. I assume it's because ^C, when running >in a dos prompt or in a bash/tcsh window, actually kills the >application, where as in EMACS, it signals the application somehow, and >Java is interpreting that signal the same was it interpreters SIGQUIT on >UNIX. Typing ^C in a command window sends a CTRL_C_EVENT signal to all processes attached to that console; the MSVC runtime converts that to SIGINT. Typing Ctrl-Break sends the CTRL_BREAK_EVENT signal, which MSVC converts to SIGQUIT. Unless the application has changed the default handlers, SIGINT and SIGQUIT both call exit() by default. Before 19.34.2, Emacs used to send CTRL_BREAK_EVENT explicitly (using GenerateConsoleCtrlEvent), and now it fakes the user typing ^C (because I can't work out how to fake the keystrokes for Ctrl-Break, and GenerateConsoleCtrlEvent can't be used anymore due to other changes). To the subprocess, the only difference should be that it now gets CTRL_C_EVENT (SIGINT) instead of CTRL_BREAK_EVENT (SIGQUIT). For some applications, that difference may be significant. Not only do some applications choose to ignore SIGINT, but Windows itself allows a parent process to arrange for its children to not even receive SIGINT at all, unless they explicitly reenable it. SIGQUIT is always received and is less likely to be ignored (so it is more likely to cause the subprocess to exit cleanly) which is why Emacs chose to use that originally. Hope this sheds some light on what's going on. AndrewI From lorenz@research.bell-labs.com Mon Jan 27 07:18:12 1997 X-VM-v5-Data: ([nil nil nil t t nil nil nil nil] [nil "Mon" "27" "January" "1997" "10:15:03" "-0500" "Lorenz Huelsbergen" "lorenz@research.bell-labs.com" "<199701271518.HAA25576@june.cs.washington.edu>" "97" "Re: NT Emacs, ^C in subshell " "^From:" nil nil "1" nil nil nil nil] nil) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id HAA25576 for ; Mon, 27 Jan 1997 07:18:11 -0800 Message-Id: <199701271518.HAA25576@june.cs.washington.edu> Received: from slocum.cs.bell-labs.com by dirty; Mon Jan 27 10:15:01 EST 1997 Received: from slocum.cs.bell-labs.com by slocum; Mon Jan 27 10:15:04 EST 1997 In-reply-to: Your message of "Wed, 22 Jan 1997 23:58:46 EST." <199701230802.AAA26547@joker.cs.washington.edu> From: Lorenz Huelsbergen To: voelker@cs.washington.edu (Geoff Voelker) Subject: Re: NT Emacs, ^C in subshell Date: Mon, 27 Jan 1997 10:15:03 -0500 Hi Geoff. Thanks for the ^C subshell info. Got SML/NJ working with (C-c C-c) as ^break over the weekend. Two more related things: 1) ^C behavior (when implemented as ^break) is a bit different than under the DOS shell. For example, if a program is doing a ReadFile from stdin, the ^C will interrupt the ReadFile, but will not make it fail until it sees eol. Under the DOS shell, this read would be going through ReadConsole, which seems to force the read to fail on ^C. Not sure if this is because it's getting a ^break or using ReadConsole. 2) (C-c C-d) sends eof but seems to do so by closing the handle associated with stdin. When sent to a program running in the shell, the program sees eof (or, more precisely, a broken pipe) but then the shell itself terminates abnormally (because, I think, stdin is no longer there). Here's a program that illustrates: #include #include main(int argc,char *argv[]) { HANDLE h; BOOL flag; char buf[100]; int dummy; h = GetStdHandle(STD_INPUT_HANDLE); flag = ReadFile(h,&buf,10,&dummy,NULL); if (!flag) { fprintf(stderr,"last error: %d\n",GetLastError()); } } Run this in the Emacs subshell and send it a C-c C-d when it's sitting in the ReadFile. I don't think the shell should terminate. These are minor points; thanks for helping me get ^C working. Lorenz >When I have Emacs generate a ctrl-c for the subprocess, the ctrl-c is >not propagated to the subprocess. However, if instead I have Emacs >generate a ctrl-break for the subprocess (which is what is currently >in 19.34), the subprocess sees the ctrl-break. I do not understand >why the ctrl-break is propagated but the ctrl-c is not. > >Unfortunately, I do not have much more time to fiddle with this right >now. A work around on your end until I am able to fix this would be >to have your ctrl-c handler also be your ctrl-break handler. This way >you will see ctrl-c's in Emacs as ctrl-break's and handle them >appropriately. > >-geoff > >Lorenz Huelsbergen writes: >> >> >> Geoff, >> >> >Yes, it looks like Emacs is not passing the ctrl-c on to the >> >subprocess correctly. It defaults to terminating the process, so I >> >need to add another case statement. >> > >> >Thanks, >> >-geoff >> >> Great. when you have a version with this working, >> we'd be happy to test it for you. >> >> Lorenz >> >> > >> >> First, thanks very much for having done the NT Emacs port and >> >> maintaining it. It's a key piece in the (seemly inevitable) >> >> transition from Unix to WindowsX that many will have to make. >> >> >> >> Second, I'm having trouble with subshells and have checked the >> >> faq but haven't found this specific problem. We have an interactive >> >> language (SML/NJ) that people frequently run as an Emacs shell. >> >> It resets the ^C handler so that a non-terminating expression >> >> can be interrupted, for example. This doesn't seem to work >> >> in NT Emacs where the ^C exits the program. My experiments to >> >> date indicate that the ^C is never handed to SML/NJ's custom >> >> ^C handler. Is this indeed the case? >> >> >> >> Thanks. >> >> >> >> Lorenz >> >