Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward
- X-seq: zsh-workers 4039
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward
- Date: Wed, 03 Jun 1998 11:09:14 +0200
- Cc: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- In-reply-to: ""Bart Schaefer""'s message of "Tue, 02 Jun 1998 10:41:16 DFT." <980602104116.ZM3619@xxxxxxxxxxxxxxxxxxxxxxx>
"Bart Schaefer" wrote:
> I don't follow how the value of lastc is related to what you describe.
> The only way it could possibly matter is if lastc == '\n'; space is the
> same as anything else, and the only reason it's set to space is to be
> something that won't compare equal to '\n'. And at the point where all
> this is happening, it won't be '\n' to begin with.
In my case it is, because the shell has been through /etc/zshenv, and
the bug still occurs. As lastc is simply a flag that data should be
flushed, it should arguably be initialised to '\n' anyway. In any
case, it worries me that inputline() is setting lastc to space when it
fails, implying the last input character has changed when the whole
problem is it hasn't --- it's effectively setting the `there's input
data to flush' flag when it knows there isn't any. That's why I think
the simplification is correct, even if there's something else wrong.
--
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx> Tel: +39 50 844536
WWW: http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy
Messages sorted by:
Reverse Date,
Date,
Thread,
Author