A parsing bug that has been around for ... years? decades?

A parsing bug that has been around for ... years? decades?

[Bart Schaefer]

Consider:

zagzig% a=( 1 2 3 4 5 )
zagzig% noglob print x=( $^a )
x=( 1 ) x=( 2 ) x=( 3 ) x=( 4 ) x=( 5 )

There are spaces around $^a, so one (or perhaps both) of the following 
should have happened:

1. 'x=(' and ')' should have been separate words, and RC_EXPAND_PARAM 
   should have had no effect at all, yielding "x=( 1 2 3 4 5 )".

2. a parse error should have occurred on the closing paren.

What apparently did happen, but IMO should not have, is that everything
in the parens was swallowed up as glob qualifiers, but then the glob was
not performed.

Consider further:

zagzig% setopt correct
zagzig% fOo() { : }
zagzig% foo
zsh: correct 'foo' to 'fOo' [nyae]? a
zagzig% noglob foo
zsh: command not found: foo

Surely noglob is not supposed to subsume the function of nocorrect?  Not
even "setopt correctall" is effective there.

The fix for both of these would appear to be that parse.c:par_simple() has 
to actually recognize noglob as a token, the way it does nocorrect, so 
that the "command position" context can be preserved for the following
word, and so that parsing of glob qualifiers can be disabled for the rest
of the command.

However, I imagine the latter would break something somewhere, so perhaps
that part should merely be better addressed in the documentation.

Re: A parsing bug that has been around for ... years? decades?

[pws]

> Consider: 
>  
> zagzig% a=( 1 2 3 4 5 ) 
> zagzig% noglob print x=( $^a ) 
> x=( 1 ) x=( 2 ) x=( 3 ) x=( 4 ) x=( 5 ) 
>  
> There are spaces around $^a, so one (or perhaps both) of the following  
> should have happened: 
>  
> 1. 'x=(' and ')' should have been separate words, and RC_EXPAND_PARAM  
>    should have had no effect at all, yielding "x=( 1 2 3 4 5 )". 
>  
> 2. a parse error should have occurred on the closing paren. 
>  
> What apparently did happen, but IMO should not have, is that everything 
> in the parens was swallowed up as glob qualifiers, but then the glob was 
> not performed. 
 
It's only indirectly to do with glob handling.  It's a long-standing feature that opening 
parentheses that aren't in command position require a matching closing 
parenthesis.  Globbing is the main use for this, but I don't think there's any 
possibility of spotting a glob qualifier as earlier as the initial parsing code. 
 
pws 
 

-- 

Whatever you Wanadoo:
http://www.wanadoo.co.uk/time/

This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm