Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.

[Jan Schampera]

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 parts inside quotes.

My personal opinion is: This makes sense. Can't speak for others.

That's also the reason you have 2 different =~ behaviours. Please, 
whatever the reasonable result of this discussion is, do not make up yet 
the next =~ variant that's incompatible with the others ;)


> 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.

== is the same as =, my suggestion is to NOT touch that. It would be 
even better to introduce a new operator instead of touching =~ (see 
above) or the pattern matchers. Maybe you don't care for compatiblity, I 
do, since I'm operating the same scripts on systems with Bash 2.05b to 
the newest 4.x without changes - so please don't suggest anything that 
will break compatiblity with very common things that were there for ages 
(like the pattern matchers in the conditional expression).


> Wouldn't it be reasonable to do RE matching when one does =~ and not
> do it when one uses ==?

For ==, see above. For the behaviour of =~: It was adjusted in 3.2 to be 
consistent with =/==. As far as I remember there was a lot of 
discussion, maybe Chet can say something about it.


> The whole point of the =~ was to allow regex matching.  If you don't
> want it, why would you have to create special, asymmetric functionality
> for quotes?

I don't really see your problem with regex matching at the moment, maybe 
I misunderstand you.

Maybe you think this means you can not match quotes in a regex at all, 
this would be totally wrong, of course you can. Just with a small syntax 
speciality (like for pattern matching, too).

The "portable" way for =~ in Bash is putting the RE into a variable, 
anyways. Not nice. Such things come up when you break compatiblity (see 
above, changed between 3.0 and 3.2).


Regards,
Jan