Zsh Mailing List Archive
Messages sorted by:
Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward
- X-seq: zsh-workers 4037
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward
- Date: Tue, 2 Jun 1998 10:41:16 -0700
- Cc: Torsten Hilbrich <Torsten.Hilbrich@xxxxxxx>
- In-reply-to: <9806021550.AA30252@xxxxxxxxxxxxxxxxx>
- References: <9806021550.AA30252@xxxxxxxxxxxxxxxxx>
On Jun 2, 5:49pm, Peter Stephenson wrote:
} Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting h
} > 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.
} It turns out to be in the input code, which is a part of the shell
} last seriously modified by me. However, there is a flag 'lastc'
} containing the last character read which I didn't touch. For some
} reason I haven't quite traced, inputline() fails and sets lastc to
} space just in this one case; inerrflush() is called to flush the
} input, and since there isn't any this sets lexstop; this is propagated
} back to the lexerr when isearch exits, which thinks it marks the end
} of input, so the shell exits.
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 short, I don't believe that your patch has anything to do with the
bug. :-) The -real- problem is:
} For some reason I haven't quite traced, inputline() fails
The reason inputline() fails is because he's interrupting it with ^C
rather than ^G. That's causing getkey() to return EOF, which doesn't
immediately have an effect, because once getkeycmd() returns NULL to
break out of doisearch(), it eventually returns to zleread() which
simply goes around the `while (!done && !errflag)' loop again. When
return is pressed, zleread() finally finishes, at which point it
returns up to gettok() with lexstop == 1, and because errflag is not
set, this is interpreted as ENDINPUT and the shell exits.
Now, having figured all that out, I have absolutely no idea what to
do about it. :-) However, I suggest NOT applying Peter's patch.
Bart Schaefer Brass Lantern Enterprises
Messages sorted by: