Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Torsten Hilbrich]

Sorry, if that bug is already known, but I haven't found any
mentioning in the BUGS file and the FAQ.

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.

Example:

~$ zsh -f
marvin% 
Press: Ctrl-R Ctrl-C Return 
Shells exit at this point
~$ 

The shell is linked with the ncurses library:

~$ ldd `which zsh` 
        libncurses.so.3.4 => /lib/libncurses.so.3.4 (0x40011000)
        libc.so.6 => /lib/libc.so.6 (0x40056000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Please sent me mail copies of your responds,

	Torsten

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Peter Stephenson]

Torsten Hilbrich wrote:
> 
> Sorry, if that bug is already known, but I haven't found any
> mentioning in the BUGS file and the FAQ.

It wasn't known to me.

> 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.

However, its only utility is as a flag that is '\n' after end of line
has been reached; it is never necessary when lexstop is also set,
since that gets checked at the same time, and also the code has no
business setting it to ' ' when inputline() fails since then there's
no line to flush.

So call me adventurous, but I think the code can be simplified so that
lastc is only modified when a real character is returned.  That's what
this does.

*** Src/input.c.inerr	Tue Jun  2 17:16:03 1998
--- Src/input.c	Tue Jun  2 17:27:31 1998
***************
*** 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

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Bart Schaefer]

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

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Peter Stephenson]

"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@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

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Peter Stephenson]

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

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Bart Schaefer]

On Jun 11,  5:26pm, Peter Stephenson wrote:
} Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting h
}
} 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.

This patch certainly does seem to stop the shell from exiting.  I still
think there's an EOF being incorrectly propagated when the bck-i-search:
prompt is interrupted with C-c, but perhaps that doesn't matter if this
masks it.  Thanks for checking again, Peter.

Side note:  What's the point of leaving out the 'a' in "bck"?  Just to
make it the same number of characters as "fwd"?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Peter Stephenson]

"Bart Schaefer" wrote:
> I still
> think there's an EOF being incorrectly propagated when the bck-i-search:
> prompt is interrupted with C-c, but perhaps that doesn't matter if this
> masks it.

I think even that's OK.  There were two distinct EOF's involved.  The
one I found from debugging was from a previous source:  it really did
reach EOF, so that was the correct behaviour.  The bug was this was 
being remembered, and later on a chain of events (flushing data when
there wasn't any causing a lexstop with no yylex active) caused
*another* EOF to be returned, this time incorrectly, from zleread().
The bug was the chain of events in between, not the EOF's.  (Or am I
missing the point?)

> Side note:  What's the point of leaving out the 'a' in "bck"?  Just to
> make it the same number of characters as "fwd"?

I suppose Paul had an aversion to typing.  Probably understandable
under the circumstances.  He was a vi user :-).

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

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Bart Schaefer]

On Jun 12, 11:16am, Peter Stephenson wrote:
} Subject: Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting h
}
} "Bart Schaefer" wrote:
} > I still
} > think there's an EOF being incorrectly propagated when the bck-i-search:
} > prompt is interrupted with C-c
} 
} The bug was the chain of events in between, not the EOF's.  (Or am I
} missing the point?)

The point is that zsh is interpreting a read(2) that gets SIGINT'd as
having reached EOF.  That doesn't affect the behavior as long as it
ignores the EOF for other reasons, but it feels like a bug waiting to
happen.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward

[Torsten Hilbrich]

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