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

[Linda Walsh]

Andreas Schwab wrote:
> Linda Walsh <bash@tlinx.org> writes:
>
> >   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).
>
> Set a='one * three' and try again.
----    
        Why?   How would that be any different than case B4 & B5 that I already 
showed?
If you don't understand my examples, I don't think you fully understand the 
problem.


> > Quoting should not disable RE matching.
>
> Yes it should.  Just like quoting disables glob matching. 
---
        Care to show me how it disables matching and NOT expansion?
Note, using "*" and "?" aren't allowed -- since you are quoting the operators!

Now show me a case where it disables matching where the operators are not 
quoted.

With =~, the operator is NOT quoted.

If you quote the operator, it will be disabled.  That is expected.  But not if 
you
quote the "operands".

Here's another example, though it could be argued that it is broken as 
implemented

1) a='2'+'3'
echo $a
5

The quotes don't disable addition.

However, it is the case that quoting the operator doesn't disable the addition:

This arguably could be considered a bug:
let b=2'+'3  #works
let b='2+'3  #works
let b=2\+3   # also works

In the above case, no application of quotes will disable the '+' operator from 
functioning
in a let statement.

So if operators don't disable arithmetic evaluation, why should it disable 
pattern-matching evaluation.

Pattern matching is not an operation of expansion the part between quotes.  
That's where you are confused.  The operation is not happening inside the quotes.

When you have
"one two three" =~ "one t.. three", there is no change made to the right hand 
operand.
You are claiming that the double quotes on the right side should disable the 
operator that
is NOT inside the quotes --- like this:

if [[ 'abc' =~ a"b". ]]; then echo you-claim-shouldn't-match, but does; fi

The double quotes don't disable the operator.  The =~ is the operator, not the 
"."
That's not the case with globbing. ;) In globbing, the operators are * and ?.
They expand (or not) to match a pattern.

That's the difference.

Pattern matching isn't controlled by the pattern -- it's controlled by the 
operator --
that's one way in which regex's are different from globbing.   That difference 
should be
preserved.

It is a difference that makes regex's usable in different ways than globbing, 
and vice-versa.

If you just wanted to make regex = globbing, that's different, but look at any 
implementation
of pattern matching.  Look at other utils that have posix style pattern 
matching -- they don't
disable the pattern match when the right hand side is quoted:

Ex. Perl:
1) > perl -e '$a="one two three";  $b="one t.. three";
   >> if ( $a =~ $b ) { print "unquoted matches\n"; } '
   unquoted matches
2) > perl -e '$a="one two three";  $b="one t.. three";
   >> if ( $a =~ "$b" ) { print "quoted matches TOO\n"; } '
   quoted matches TOO

So tell me under what circumstances, algorithms can't be written in perl because
double quotes don't disable pattern matching.

How about grep?

1) echo 'one two three'|grep t..
  one two three
2) echo 'one two three'|grep "t.."
  one two three

Again, quotes don't turn off matching.  Can you explain how grep is broken 
because
of this?

Please demonstrate with actual examples.



> There must be
> a way to remove the special meaning of a character.

Which character are you trying to disable?  The ****standard**** way to get
characters in a regex to lose their normal meanings is to ESCAPE them.  That's
STANDARD in how regex's work in unix/linux/posix.   Why should BASH be
incompatible?


> Globbing is not only about expansion, it is also about matching.
---
                I claim there is no case where the globbing characters are
not expanded to zero or more matching characters in order to perform a
match.  Show me a case where this isn't the case and where double quotes
change the sense of the answer.  Notice how you makes claims in your 
post, but provide no examples?  

        Regex's are not globbing -- the are conceptually different -- and that
seems to be where the confusion is.  Regex's SHOULDN'T act like globbing because
they are not the same feature -- that was part of the point of adding them --
to add a new feature with *different functionality* from globbing.  Bastardizing
regex's to make them a little more like globbing is not a supportable position.  
There's no reason to do it and it makes it incompatible not only with other 
posix and gnu utils in regex handling, but also makes Bash internally inconsistent
with itself.  That's at least 2 strikes against this lameness.  More if you
look at the number of inconsistencies that breaking quoting causes.