Re: Regex matching oddity (bug, or 'unexpected feature' or...?)

[pk]

On Thursday 28 May 2009 21:58, Linda Walsh wrote:

> But when I used regex pattern matching in the if, the spaces around the
> operator
> caused a failure in matching.  I.e.:
> if [[ "$Var"=~"+([:digit:])" ]] ; then ...
> worked.

"worked" in the sense that [[ .. ]] evaluated a single argument: the
string "$Var"=~"+([:digit:])". Not different from doing, for instance, 

if [[ "foobar" ]]; then ...

 
> But:
> if [[ "$Var" =~ "+([:digit:])" ]] ; then ...
> evaluates to 'FALSE', trace(-x) shows the eval as:
> + [[ 4 =~ \+\(\[:digit:]\) ]]

Yes, if the second argument is quoted, it's treated as a literal string. If
you want the regex behavior, you should not quote it:

if [[ "$Var" =~ +([:digit:]) ]]; then .

That behavior changed at some point during 3.2 (too lazy to check now).

> and inserting a space on only-one side of the operator yielded the error
> message:
> "conditional binary operator expected"
> at the line of the expression.

Expected: having the space only on side is just like evaluating

if [[ "foo" "bar" ]]; then ...

in your case the two strings are

"$Var"=~  and   "+([:digit:])"

or

"$Var"    and   =~"+([:digit:])"

depending on where you put the space.

> Obviously, I can workaround my mis-comprehension and just proceed,
> but I wanted to ask why, what I thought was "normal" syntax,
> (i.e. args separated by spaces), didn't work.

It did work as documented, although I agree that the change in behavior in
regex match I mentioned before took many by surprise, since your same
question has been asked several time in the past.