From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 17286 invoked from network); 11 Jun 1998 15:46:04 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 11 Jun 1998 15:46:04 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.8.5/8.8.5) id LAA03592;
	Thu, 11 Jun 1998 11:29:48 -0400 (EDT)
Resent-Date: Thu, 11 Jun 1998 11:29:48 -0400 (EDT)
Message-Id: <9806111526.AA19795@ibmth.df.unipi.it>
To: zsh-workers@math.gatech.edu
Cc: Torsten Hilbrich <Torsten.Hilbrich@gmx.net>
Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 
In-Reply-To: "Torsten Hilbrich"'s message of "01 Jun 1998 21:57:50 DFT."
             <877m30ki81.fsf@marvin.bln.de> 
Date: Thu, 11 Jun 1998 17:26:04 +0200
From: Peter Stephenson <pws@ibmth.df.unipi.it>
Resent-Message-ID: <"-he0t.0.3u.hV_Vr"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/4095
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

Torsten Hilbrich wrote:
> If I startup the zsh I immediatly history-incremental-search-backward
> (^R) in the history.  Instead of executing the found command I simply
> abort using ^C.  Then the next return with or without any command
> given will immediatly exit the shell.  It also happens if there is no
> match found in the backward search.

I had a look at this again, and I believe my previous analysis, that
the lastc variable wasn't getting set properly, was the correct
one.  This time I followed the problem at bit further back.
In my case, /etc/zshenv was being sourced immediately before the
command loop started.  At EOF, inputline() returned false; this caused
ingetc() to set lastc to ' ', the behaviour which I found suspect.
Thus the first time from zleread(), inerrflush() tested lastc, found
it wasn't \n, and assumed, wrongly, there was some junk to flush out.
Knock-on errors from this caused the shell to exit.  Later on, lastc
would be \n because the last input operation was a read from stdin
which didn't return EOF. (You can get the same behaviour at any time
by sourcing a file, followed by the actions Torsten described.)

If there was no /etc/zshenv to source, lastc still wouldn't be \n
because it wasn't initialised, so the same thing happens.

So my patch was correct, with one thing I forgot about:  lastc should
be initialised to \n at startup as a flag that there is no input to
flush.  Here is the complete thing.

*** Src/input.c.inerr	Tue Jun  2 17:16:03 1998
--- Src/input.c	Thu Jun 11 17:01:48 1998
***************
*** 101,107 ****
  static int inbufleft;		/* Characters left in current input
  				   stack element */
  
! static int lastc;		/* used as flag that end of line was reached */
  
  
   /* Input must be stacked since the input queue is used by
--- 101,107 ----
  static int inbufleft;		/* Characters left in current input
  				   stack element */
  
! static int lastc = '\n';	/* used as flag that end of line was reached */
  
  
   /* Input must be stacked since the input queue is used by
***************
*** 179,185 ****
  ingetc(void)
  {
      if (lexstop)
! 	return lastc = ' ';
      for (;;) {
  	if (inbufleft) {
  	    inbufleft--;
--- 179,185 ----
  ingetc(void)
  {
      if (lexstop)
! 	return ' ';
      for (;;) {
  	if (inbufleft) {
  	    inbufleft--;
***************
*** 202,212 ****
  	 */
  	if (strin || errflag) {
  	    lexstop = 1;
! 	    return lastc = ' ';
  	}
  	/* As a last resort, get some more input */
  	if (inputline())
! 	    return lastc = ' ';
      }
  }
  
--- 202,212 ----
  	 */
  	if (strin || errflag) {
  	    lexstop = 1;
! 	    return ' ';
  	}
  	/* As a last resort, get some more input */
  	if (inputline())
! 	    return ' ';
      }
  }
  

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 50 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy