On 9/18/10 2:45 PM, Linda Walsh wrote:
>
>
> 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.
Wow. Really?
> 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.
Huh? Pattern matching and regular expressions are pretty much the same
thing. There are characters that match themselves, and there are
characters that match zero or more characters besides themselves. When
in a context that allows pattern matching, such as filename generation
or a case statement, the characters special to pattern matching have
meaning. When they're not in such a context, like the rhs of an assignment
statement or words within [[...]], they don't. Filename generation is
so pervasive in the shell that it's easy to miss this.
> You can't type
>
> ls t..
>
> and expect it to do a regex match.
Sure, because that's not the defined behavior. On the other hand, you
can't type f=t?? and expect it to perform a pattern 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.
OK. One more time.
The 'pattern' used with your pattern matching example has no characters
special to pattern matching. Quoting that pattern, which forces it to
be matched as a string, doesn't matter. There are no characters which
would behave differently if the pattern were not quoted.
The pattern matching equivalent of the `t..' regexp would be `t??'. You
don't use it. You use a string (`two') instead.
>> 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.
== is an operator that is defined to treat its rhs as a pattern and perform
pattern matching. Quoting allows you to remove the special meaning of
any characters that can match characters besides themselves. == does not
perform string comparison.
> 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.
No, it doesn't. There's no 'substitution' involved. There's no string
comparison involved. It's a pattern match. If the pattern matches, the
result is true.
>
> IT isn't the == operator that turns t??t into something that can match 'test'
It absolutely is. If you don't think so, you fundamentally misunderstand
its purpose and operation.
> 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.
This is total gibberish.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
