I prefer plan C: leave it alone. It's working fine.
Pierre Gaston wrote:
what about:
[[ foo =~ bar && baz ]]
Should bar && baz be considered as one regexp? if not, how would you
write a regexp matching
`foo && baz' ? or `foo && baz.*' ?
Use parentheses to disambiguate ambiguous cases?
if yes how would you do and and
with a r
On Mon, Sep 20, 2010 at 10:28 PM, Linda Walsh wrote:
>
>
> Pierre Gaston wrote:
>
>> Just quote the spaces and not the special chars:
>
> Pierre, your suggestion doesn't help clean up strings used inside of double
> brackets. I wanted to avoid the need for multiple backslashes in an
> expression
Pierre Gaston wrote:
Just quote the spaces and not the special chars:
Pierre, your suggestion doesn't help clean up strings used inside of double
brackets. I wanted to avoid the need for multiple backslashes in an expression
as it makes the expression less readable and more error prone.
On Sun, Sep 19, 2010 at 2:54 AM, Linda Walsh wrote:
> O rats, I think I understand why you have the double q'marks do what they do
> in double brackets.
> 1) Even though I've seen the construct many times, I've almost never use
> glob->expression matching in a case statement. It would appear
> t
O rats, I think I understand why you have the double q'marks do what they do
in double brackets.
1) Even though I've seen the construct many times, I've almost never use
glob->expression matching in a case statement. It would appear
that is the only place a glob can match an expression in 'o
On 9/18/10 6:12 PM, Linda Walsh wrote:
>
>
>>
>>> 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.
> ---
>
> Then where is the operator when you take
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.
---
Then where is the operator when you take the same chararcters
t??t and place them as an argument t
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 consi
On Sat, Sep 18, 2010 at 9:45 PM, Linda Walsh wrote:
>
> 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 subst
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 mat
I'm sorry to not answer a message directly, but I didn't get the mails
of this list during the last day - no idea why. Quoting text from the
pipermail archive.
>> After initialÄy introducing =~, Chet made it consistent with =/==
>> in a second version, means: =/== doesn't do pattern matching f
On Sat, Sep 18, 2010 at 3:36 AM, Linda Walsh wrote:
>
> ---
> 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.
glob="f??"
re="f.."
echo case:
c
On 9/17/10 8:36 PM, Linda Walsh wrote:
> 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.
>
>
On 9/17/10 8:20 PM, Linda Walsh wrote:
>
>
> Andreas Schwab wrote:
>> Linda Walsh 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 m
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 str
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
Andreas Schwab wrote:
Linda Walsh 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
Linda Walsh 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
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 =~ b
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 part
Why do (or should) double quotes lose their normal meaning inside
double brackets?
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.
Wouldn't it be re
22 matches
Mail list logo
