From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 28714 invoked from network); 13 Jun 1998 15:18:07 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 13 Jun 1998 15:18:07 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.8.5/8.8.5) id LAA13677;
	Sat, 13 Jun 1998 11:02:27 -0400 (EDT)
Resent-Date: Sat, 13 Jun 1998 11:02:27 -0400 (EDT)
Sender: hilbrich@vossnet.de
To: Peter Stephenson <pws@ibmth.df.unipi.it>
Cc: zsh-workers@math.gatech.edu
Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward
References: <9806111526.AA19795@ibmth.df.unipi.it>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Torsten Hilbrich <Torsten.Hilbrich@gmx.net>
Date: 12 Jun 1998 23:41:10 +0200
In-Reply-To: Peter Stephenson's message of "Thu, 11 Jun 1998 17:26:04 +0200"
Message-ID: <87yav2l2mh.fsf@marvin.bln.de>
X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald"
X-Face:  &h3VJ.Wf$"FwQv&ybX66{lt4*Mo%#kP6^"eU?7~UHhgF6l7)UB0f~g'}64W-b{tK1Jyh)^!
 %sc(cpH%Yv}bh"VwaJ>>!Kv*k4EJn^Lt[X|f<
Resent-Message-ID: <"576kF1.0.eL3.3IfWr"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/4107
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu


On: Thu, 11 Jun 1998 17:26:04 +0200 Peter Stephenson writes:

> 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.
> [patch removed]

I just applied the patch and the error is gone.  If there are any
side-effects that I notice, I will reply directly to Peter.

Thanks to everyone for your efforts,

	Torsten

-- 
Whenever a system becomes completely defined, some damn fool discovers
something which either abolishes the system or expands it beyond recognition.
							Fortune Cookie
PGP Public key available