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 <voelker@cs.washington.edu>; 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 <lorenz@research.bell-labs.com>
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 <windows.h>
#include <stdio.h>

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