* Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward @ 1998-06-01 19:57 Torsten Hilbrich 1998-06-02 15:49 ` Peter Stephenson 1998-06-11 15:26 ` Peter Stephenson 0 siblings, 2 replies; 9+ messages in thread From: Torsten Hilbrich @ 1998-06-01 19:57 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-01 19:57 Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward Torsten Hilbrich @ 1998-06-02 15:49 ` Peter Stephenson 1998-06-02 17:41 ` Bart Schaefer 1998-06-11 15:26 ` Peter Stephenson 1 sibling, 1 reply; 9+ messages in thread From: Peter Stephenson @ 1998-06-02 15:49 UTC (permalink / raw) To: Zsh hackers list; +Cc: Torsten Hilbrich 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-02 15:49 ` Peter Stephenson @ 1998-06-02 17:41 ` Bart Schaefer 1998-06-03 9:09 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Bart Schaefer @ 1998-06-02 17:41 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list; +Cc: Torsten Hilbrich 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-02 17:41 ` Bart Schaefer @ 1998-06-03 9:09 ` Peter Stephenson 0 siblings, 0 replies; 9+ messages in thread From: Peter Stephenson @ 1998-06-03 9:09 UTC (permalink / raw) To: Zsh hackers list; +Cc: Bart Schaefer "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-01 19:57 Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward Torsten Hilbrich 1998-06-02 15:49 ` Peter Stephenson @ 1998-06-11 15:26 ` Peter Stephenson 1998-06-12 2:58 ` Bart Schaefer 1998-06-12 21:41 ` Torsten Hilbrich 1 sibling, 2 replies; 9+ messages in thread From: Peter Stephenson @ 1998-06-11 15:26 UTC (permalink / raw) To: zsh-workers; +Cc: Torsten Hilbrich 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-11 15:26 ` Peter Stephenson @ 1998-06-12 2:58 ` Bart Schaefer 1998-06-12 9:16 ` Peter Stephenson 1998-06-12 21:41 ` Torsten Hilbrich 1 sibling, 1 reply; 9+ messages in thread From: Bart Schaefer @ 1998-06-12 2:58 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-12 2:58 ` Bart Schaefer @ 1998-06-12 9:16 ` Peter Stephenson 1998-06-12 15:38 ` Bart Schaefer 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 1998-06-12 9:16 UTC (permalink / raw) To: Zsh hackers list "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-12 9:16 ` Peter Stephenson @ 1998-06-12 15:38 ` Bart Schaefer 0 siblings, 0 replies; 9+ messages in thread From: Bart Schaefer @ 1998-06-12 15:38 UTC (permalink / raw) To: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward 1998-06-11 15:26 ` Peter Stephenson 1998-06-12 2:58 ` Bart Schaefer @ 1998-06-12 21:41 ` Torsten Hilbrich 1 sibling, 0 replies; 9+ messages in thread From: Torsten Hilbrich @ 1998-06-12 21:41 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1998-06-13 15:18 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-06-01 19:57 Bugreport zsh 3.1.2: Shell exits prematurely after aborting history-incremental-search-backward Torsten Hilbrich 1998-06-02 15:49 ` Peter Stephenson 1998-06-02 17:41 ` Bart Schaefer 1998-06-03 9:09 ` Peter Stephenson 1998-06-11 15:26 ` Peter Stephenson 1998-06-12 2:58 ` Bart Schaefer 1998-06-12 9:16 ` Peter Stephenson 1998-06-12 15:38 ` Bart Schaefer 1998-06-12 21:41 ` Torsten Hilbrich
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).