bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Linda Walsh
Subject: Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Date: Fri, 17 Sep 2010 17:36:41 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Thunderbird/2.0.0.24 Mnenhy/0.7.6.666



Jan Schampera wrote:
Linda Walsh wrote:

Why do (or should) double quotes lose their normal meaning inside
double brackets?

After initialĺy introducing =~, Chet made it consistent with =/== in a second version, means: =/== doesn't do pattern matching for parts inside quotes, =~ doesn't du regexp matching for parts inside quotes.
----
        Except this isnt' true.   Quoting example C:

t='one two three'
a='one two three'
1) if [[ $t == $a ]]; then echo 'Matches'; fi
2) if [[ $t == "$a" ]]; then echo 'Matches'; fi examples.

The above does match.  the pattern in $a matches the pattern
in $t whether it is in quotes or not.

But with =~ it is different:
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

They don't behave the same.
My personal opinion is: This makes sense. Can't speak for others.
---
        If you would show me an example where pattern matching is
disabled with ==, I might be more inclined to agree.  But as I
showed above, the pattern in $a matches regardless of double quoting.


That's also the reason you have 2 different =~ behaviours. Please, whatever the reasonable result of this discussion is, do not make up yet the next =~ variant that's incompatible with the others ;)
----
        No...I'm pushing back on the incompatibility introduced after 3.1.


I would like to see double quotes and single quotes NOT disable
RE functionality when used with =~.  I would like to suggest that to
disable RE functionality, that the user use '==', instead.

== is the same as =, my suggestion is to NOT touch that.
----
        You are not understanding my examples or what is going on.
No where is there a change being suggested for ==.   What I suggest is
how ==/= already works.  That's the lunacy of breaking =~ --- apparently
people arguing against =~ meaning RE, don't know that literal matching
is what already happens with the == operator (subject to variable expansion
with double quotes, and no variable expansion inside of single quotes).
That's the way Bash has always operated.  I'm not suggesting any change to
that.

But what's happening here is that quotes are having an effect on the =~ 
operator.
That would be similar (if you were right) to quotes disabling matching with == as well -- but it doesn't. That's why I claim =~ shouldn't either.


        I'm not going to respond to the rest of your post, as it appears
you are posting under some misunderstanding of how bash currently works, so
it's not really useful to respond to a position that doesn't really exist
(at least not how I understand you saying it! ;-)).






reply via email to

[Prev in Thread] Current Thread [Next in Thread]