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: Sat, 18 Sep 2010 11:45:06 -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



Chet Ramey wrote:
On 9/17/10 6:50 PM, Linda Walsh wrote:

Jan Schampera wrote:
== is the same as =, my suggestion is to NOT touch that.
===

I'm not going to say too much on this.  The behavior as it exists now
is very consistent: for both == and =~, any part of the rhs that's quoted
is matched as a string.  Period.  It was a mistake not to do it that
way in the first place.
---
No it wasn't. Because a regex is NOT inherently a regex, globbing chars ARE.

        You put quotes around glob characters to stop their 'globbing',
because it is the characters that 'glob'.  The same is not true of regex
expressions.  Regex expressions are simple strings.  Period.  They have
no special meaning apart from use with "=~" or some similar operator.


You can't type

        ls t..

and expect it to do a regex match.
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....

Again, the examples are not equivalent.
---
Why not?  They They are both simple strings.

If you put the simple string on a line as an arg to to echo or ls, it won't expand into something else. Glob chars will. Why, because
it is the glob chars that are the 'operator'.  Glob chars aren't constants.
they are operators.   You quote them to remove their operator properties.
But with regex's you don't have to quote them to make them lose their
function -- they have no function by themselves.

It is only in the presence of a special operator that says "treat the rhs
as a regex", that they have any meaning.

There is no language where quoting a regex makes it NOT a regex.  It may
change what you are matching, but quotes never deactivate matching when it
would otherwise have occurred.



You're not helping your argument any by using examples that can at best
be considered disingenuous and at worst deliberately misleading.


How are they misleading?

I use == to compare constant strings.
When you compare 'test' with t??t, the globbing operator has precedence and
attempts to match the string t??t against test.  If it can match the glob
pattern against the intput 'test', then it substitutes in the literal string 
'test' and that result is passed the the '==' operator, which returns true.

IT isn't the == operator that turns t??t into something that can match 'test'.
t??t will match 'test' in an 'echo' statement or in an 'ls' statement if there is a file by that name in your current directory.
In the case of =~ == it's an "override operator" that says to treat the rhs
as a regex.  Quoting it doesn't change anything because the regex is already
in its terminal form before the match is attempted.  There are no active
characters in the regex to deactivate.

To make the characters in the regex lose their meaning, you remove the
regex operator, '=~', and replace it with '=='.

It's the =~ that creates the rhs as a regex -- NOT the characters themselves.

That's the difference and that why putting quotes around 'inactive' characters 
should make no difference in how ANOTHER operator (the =~) treats them.

Am I making sense yet?






reply via email to

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