From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25325 invoked from network); 24 Jun 1998 09:00:13 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 24 Jun 1998 09:00:13 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id EAA09283; Wed, 24 Jun 1998 04:54:49 -0400 (EDT) Resent-Date: Wed, 24 Jun 1998 04:54:49 -0400 (EDT) Message-Id: <9806240851.AA45920@ibmth.df.unipi.it> To: zsh-workers@math.gatech.edu (Zsh hackers list) Cc: Tanaka Akira Subject: Re: zsh exits suddenly. In-Reply-To: ""Bart Schaefer""'s message of "Tue, 23 Jun 1998 11:25:17 DFT." <980623112518.ZM375@candle.brasslantern.com> Date: Wed, 24 Jun 1998 10:51:16 +0200 From: Peter Stephenson Resent-Message-ID: <"thYfh2.0.-G2.OxBar"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4161 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu "Bart Schaefer" wrote: > On Jun 23, 11:45pm, Tanaka Akira wrote: > } Subject: zsh exits suddenly. > } > } I have a trouble that zsh exits as following. > } > } carbon% ls <^D> > } zsh: do you wish to see all 848 possibilities? <^C>n > } carbon% ls <^M> > } akr@carbon% > > I finally figured out where that's happening -- it's in ingetc(), which > is called from the SIGINT handler() via inerrflush(). However, I still > don't know how to fix the problem. You were right, the problem is more general than the one I fixed in http://www.zsh.org/mla/workers-1998/msg00430.html . How about this? It says 'don't flush input if there aren't any characters to flush'. It's hard to see how that can be wrong, since ingetc() always fetches new data a line at a time. It seems to work. I think setting lexstop to 0 in the signal code is too drastic: it should never have got to 1 in the first place. More technical notes: I can't be absolutely sure if all that lastc stuff is really needed. It means, of course, that if there is more than one line in the buffer, only the current one is flushed. Is this the right behaviour? As you can see from the 'strin' test, if the data being read is a single string (e.g. from a $(...) substitution) it dumps the whole lot anyway. Before I rewrote the input stuff, everything was shoved onto a single string, so it was harder to tell when you had to stop flushing it: I wimped out on removing the lastc stuff since I wrongly thought it wasn't doing any harm. Maybe I'll experiment here with eliminating all the lastc nonsense and just testing inbufct. The comment in inerrflush() may be a red herring, it dates from before the new code. *** Src/input.c.lastc Wed Jun 24 10:24:24 1998 --- Src/input.c Wed Jun 24 10:32:39 1998 *************** *** 427,433 **** * it is only used in the history code, where that is the only * completely safe way of discarding input. */ ! while ((strin || lastc != '\n') && !lexstop) ingetc(); } --- 427,433 ---- * it is only used in the history code, where that is the only * completely safe way of discarding input. */ ! while ((strin || lastc != '\n') && !lexstop && inbufct) ingetc(); } -- Peter Stephenson Tel: +39 50 844536 WWW: http://www.ifh.de/~pws/ Gruppo Teorico, Dipartimento di Fisica Piazza Torricelli 2, 56100 Pisa, Italy