From lorenz@research.bell-labs.com Wed Jan 22 15:12:11 1997 X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] [nil "Wed" "22" "January" "1997" "18:10:19" "-0500" "Lorenz Huelsbergen" "lorenz@research.bell-labs.com" "<199701222312.PAA00230@june.cs.washington.edu>" "34" "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.3+CSE/7.2ju) with SMTP id PAA00230 for ; Wed, 22 Jan 1997 15:12:10 -0800 Message-Id: <199701222312.PAA00230@june.cs.washington.edu> Received: from slocum.cs.bell-labs.com by dirty; Wed Jan 22 18:10:19 EST 1997 Received: from slocum.cs.bell-labs.com by slocum; Wed Jan 22 18:10:20 EST 1997 In-reply-to: Your message of "Tue, 21 Jan 1997 23:22:32 EST." <199701220726.XAA27320@joker.cs.washington.edu> From: Lorenz Huelsbergen To: voelker@cs.washington.edu (Geoff Voelker) Subject: Re: NT Emacs, ^C in subshell Date: Wed, 22 Jan 1997 18:10:19 -0500 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 > From lorenz@research.bell-labs.com Mon Jan 27 07:18:12 1997 X-VM-v5-Data: ([nil nil nil nil 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 >> > From lorenz@research.bell-labs.com Mon Feb 3 08:03:27 1997 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil "Mon" " 3" "February" "1997" "11:02:13" "-0500" "Lorenz Huelsbergen" "lorenz@research.bell-labs.com" nil "23" "Re: NT Emacs, ^C in subshell " "^From:" nil nil "2" 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 IAA13784 for ; Mon, 3 Feb 1997 08:03:20 -0800 Message-Id: <199702031603.IAA13784@june.cs.washington.edu> Received: from slocum.cs.bell-labs.com by dirty; Mon Feb 3 11:02:36 EST 1997 Received: from slocum.cs.bell-labs.com by slocum; Mon Feb 3 11:02:38 EST 1997 In-reply-to: Your message of "Mon, 27 Jan 1997 22:15:55 EST." <199701280628.WAA21300@joker.cs.washington.edu> From: Lorenz Huelsbergen To: voelker@cs.washington.edu (Geoff Voelker) Subject: Re: NT Emacs, ^C in subshell Date: Mon, 03 Feb 1997 11:02:13 -0500 >> 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: > >the code in Emacs explicitly sends a C-d character to the process' >input when you type C-c C-d in a shell buffer, so I'm not sure what is >going on; I would have to try and track things in a debugger. another >one for the todo list. It looks like the eof that's put in the input stream closes the input stream. If this input stream is also the subshell's input, then the subshell is in trouble. It may have to reestablish it's std streams when a process terminates. Just a hunch; this may not at all be the problem. > >-geoff Lorenz