parse errors and up-line-or-history

parse errors and up-line-or-history

[E. Jay Berkenbilt]

If you type

zsh% for in *; do echo $i; done

(instead of for i in *...; i.e., forget the variable name in the for)

you get 

zsh: parse error near `do'

which seems entirely reasonable.  If you then do ^p to fix it, you see
only

zsh% for in *; do

and not the whole command.  It would be nice if the whole command
including whatever part appears after the parse error got inserted
into history since it would be much easier to go back and fix the
typo. :-)

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

Re: parse errors and up-line-or-history

[Bart Schaefer]

On Oct 17,  3:35pm, E. Jay Berkenbilt wrote:
> 
> zsh% for in *; do echo $i; done
> zsh: parse error near `do'
> 
> which seems entirely reasonable.  If you then do ^p to fix it, you see
> only
> 
> zsh% for in *; do
> 
> and not the whole command.

Congratulations, you've revived the "literal vs. lexical history" debate,
if it ever really was a debate.

Zsh used to have an option to store the command history as the literal
input text, rather than as lexical words.  IIRC, it actually stored both
and let you select which one to retrieve.  The duplication was resolved
in favor of lexical history a *very* long time ago, with the side-effect
that anything that won't lex, doesn't make it into the history.

For a partial workaround, see zsh-workers/10996.

Re: parse errors and up-line-or-history

[E. Jay Berkenbilt]

>   > zsh% for in *; do echo $i; done
>   > zsh: parse error near `do'
>   > 
>   > which seems entirely reasonable.  If you then do ^p to fix it, you see
>   > only
>   > 
>   > zsh% for in *; do
>   > 
>   > and not the whole command.
>
>   Congratulations, you've revived the "literal vs. lexical history" debate,
>   if it ever really was a debate.
>
>   Zsh used to have an option to store the command history as the literal
>   input text, rather than as lexical words.  IIRC, it actually stored both
>   and let you select which one to retrieve.  The duplication was resolved
>   in favor of lexical history a *very* long time ago, with the side-effect
>   that anything that won't lex, doesn't make it into the history.
>
>   For a partial workaround, see zsh-workers/10996.

This workaround does exactly what I want.  I just bound your
zle-fetch-previous and zle-fetch-next to ^x^p and ^x^n respectively so
I get the benefits of the lexical history except when I really want
the other in which case I can specify it directly.  Thanks.

                                Jay

Re: parse errors and up-line-or-history

[Peter Stephenson]

Bart wrote:
> On Oct 17,  3:35pm, E. Jay Berkenbilt wrote:
> > 
> > zsh% for in *; do echo $i; done
> > zsh: parse error near `do'
> > 
> > which seems entirely reasonable.  If you then do ^p to fix it, you see
> > only
> > 
> > zsh% for in *; do
> > 
> > and not the whole command.
>
> Zsh used to have an option to store the command history as the literal
> input text, rather than as lexical words.  IIRC, it actually stored both
> and let you select which one to retrieve.  The duplication was resolved
> in favor of lexical history a *very* long time ago, with the side-effect
> that anything that won't lex, doesn't make it into the history.

There was originally a partial fix that the rest of the line gets read in
and stuck on the end of the history without lexing.  I haven't looked at
this for a long time, so it may be at the mercy of various flags which
abort what you're doing.  It might be possible to get it working.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: parse errors and up-line-or-history

[Bart Schaefer]

On Oct 18, 10:08am, Peter Stephenson wrote:
}
} Bart wrote:
} > that anything that won't lex, doesn't make it into the history.
} 
} There was originally a partial fix that the rest of the line gets read in
} and stuck on the end of the history without lexing.  I haven't looked at
} this for a long time, so it may be at the mercy of various flags

Aha!  It's HIST_REDUCE_BLANKS!  Unset that option, and the entire command
line makes it into the history.

Wayne, are you listening?

The other stuff I talked about in 10996, e.g. editing the line from before
history expansion was done, still applies.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: parse errors and up-line-or-history

[Wayne Davison]

On Wed, 18 Oct 2000, Bart Schaefer wrote:
> Aha!  It's HIST_REDUCE_BLANKS!  Unset that option, and the entire command
> line makes it into the history.

Yes, histreduceblanks() expects all the content on the line to be
represented in the chwords[] array so that it can tell which spaces are
significant and which aren't.  There are a few solutions I can think of.
One would be to add the unparsed part of the line to chwords[].  Another
would be to have histreduceblanks() notice the extra content beyond the
last chwords[] item and preserve it.  The easiest one, though, is to not
try to reduce the blanks on a line that didn't parse right.  I opted for
this last solution for now:

Index: Src/hist.c
@@ -1063,11 +1063,12 @@
 	}
 #endif
 	/* get rid of pesky \n which we've already nulled out */
-	if (chwordpos > 1 && !chline[chwords[chwordpos-2]])
+	if (chwordpos > 1 && !chline[chwords[chwordpos-2]]) {
 	    chwordpos -= 2;
-	/* strip superfluous blanks, if desired */
-	if (isset(HISTREDUCEBLANKS))
-	    histreduceblanks();
+	    /* strip superfluous blanks, if desired */
+	    if (isset(HISTREDUCEBLANKS))
+		histreduceblanks();
+	}
 	if ((isset(HISTIGNOREDUPS) || isset(HISTIGNOREALLDUPS)) && he
 	 && histstrcmp(chline, he->text) == 0) {
 	    /* This history entry compares the same as the previous.

I've tested this, and it appears to work fine, so I think I'll go ahead
and check it in.

..wayne..