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.
