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

[pws@xxxxxxxxxxxxxxxxxxxxxxxx]

> 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