From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4901 invoked from network); 2 Jun 1998 17:45:52 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 2 Jun 1998 17:45:52 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id NAA13758; Tue, 2 Jun 1998 13:40:49 -0400 (EDT) Resent-Date: Tue, 2 Jun 1998 13:40:49 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980602104116.ZM3619@candle.brasslantern.com> Date: Tue, 2 Jun 1998 10:41:16 -0700 In-Reply-To: <9806021550.AA30252@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward" (Jun 2, 5:49pm) References: <9806021550.AA30252@ibmth.df.unipi.it> X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Stephenson , zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward Cc: Torsten Hilbrich MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"s8Gdj1.0.vM3.Wa3Tr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4037 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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 http://www.well.com/user/barts http://www.brasslantern.com