Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.

[Linda Walsh]

Jan Schampera wrote:
> == is the same as =, my suggestion is to NOT touch that. 
===
        Nothing I am suggesting would touch =/==.  They behave exactly
as one would expect.  Single quotes do not allow expansion of
variables, double quotes do expansion of variables.  I.e.

I'm asking that =~ behave consistently with respect
to quotes as '==' does.  There is no reason to have the =~ be disabled
with double quotes: the == doesn't disable double-quote functionality --
it would be like *changing* double quotes, when used with "=/==", to
NOT expand variables.

Single quotes do not allow expansion of
variables, double quotes do expansion of variables.  I.e.

A. 
t='one two three'
a='two'
1) if [[ $t == 'one $a three']]; then echo 'no match expected'; fi
2) if [[ $t == "one $a three"]]; then echo 'Matches'; fi
3) if [[ $t == one\ $a\ three ]]; then echo 'Matches'; fi

So for =/==, double quotes allows *grouping* and is equivalent to 3.
But for the =~, it is broken:

B.
t='one two three'
a='t..'
1) if [[ $t =~ 'one $a three' ]]; then echo 'no match expected'; fi
2) if [[ $t =~ "one $a three" ]]; then echo 'SHOULD Match'; else echo 'BUG, 
double quotes disable match'; fi
3) if [[ $t =~ one\ $a\ three ]]; then echo 'Matches'; fi

-- but even more of the badness, single quotes disable matching entirely:
4) if [[ $t =~ one\ t..\ three ]]; then echo 'Matches'; fi
5) if [[ $t =~ 'one t.. three' ]]; then echo 'SHOULD Match'; else echo 'BUG, 
double quotes disable match'; fi

  Or another disparity:  
C.
t='one two three'
c='one two three'
1) if [[ $t == $a ]]; then echo 'Matches'; fi
2) if [[ $t == "$a" ]]; then echo 'Matches'; fi
So, the expressions match whether or not $a is in double quotes or not
(single quotes would not match, as the $a would be taken literally).

But, with the operator that says 'take right hand expression as 'RE', do we
get consistent behavior?:
t='one two three'
a='one t.. three'
3) if [[ $t =~ $a ]]; then echo 'Matches'; fi
4) if [[ $t =~ "$a" ]]; then echo 'SHOULD Match'; else echo 'BUG, double quotes disable match'; fi 

Now, double quotes Don't behave consistently -- AGAIN....

This is what I am talking about.

Quoting should not disable RE matching.  Period.  If the user doesn't want 
RE' matching then they should use '=/=='.  The =~ operator shouldn't be 
overloaded with inconsistent or broken operations. It's bad grammar.

I can't see how this could ever be considered a good thing.  It breaks
semantic compatibility and expectations of how single and double quotes
function.  

It is NOT the same as double quotes not allowing *file glob expansion*. 
There is no *expansion* going on.  The right hand is a static pattern.  
But it's still a pattern. It doesn't 'expand' like "*" does outside of 
quotes in filename expansion.

The equivalent idea of:
i) ls *
 vs.
ii) ls "*"
where, double (or single) quotes disable the file globbing operator 
from expanding, would be to quote the =~ operator (which would often 
result in a syntax error, BUT, you could do the following:

iii)  if [[ "$t =~ anything" ]]; then echo 'Matches'; fi

That will match -- because the expression is non-zero and not-null.

But quotes only disable operators normal function when they are around
the operator -- not when they are around the operands.

Does that make sense?  There is no suggestion on the table to
change the operation of '=/==', just to make quotes function the
same with =~ as they do with ==.  Right now, the meaning of 
double quotes is broken and has been overloaded with a special
case that makes no sense.

If someone needs the broken semantics. then make it clear
and add a switch shopt -o 'quotes-disable-regex-matching',
but that shouldn't be the default behavior as the above
examples show it being incompatible with how quotes have
historically been handled.


Linda