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

[Linda Walsh]

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 'old shell' (w/o
the double brackets), yes?

So [[ ]] changes the syntax such that matching is only performed against 
arguments in the command line, *instead* of against the fs(filesystem).

Thus to parallel the implementation of expansion against the command line 
and the fact that quotes disable such expansion, (while dq's still allow
the variable substitution), [[ ]] was introduced (among, perhaps other 
reasons I am not listing).

In a way, dbrkts are the same as sbrkts, but double quoting is assumed
around the arguments so 'variables' with embedded spacing are handled
properly.  Since it's already a quoted expression (sorta), adding 
quotes disables the matching.  

However, 1 disparity == a regex in single brackets is in no danger of
matching against the file system OR at all (unless by accident), as
regex's are only seen as such next to =~ in dbrkts.

Hmmm..

Then what possible interpretations could this have:

a='one two three'
if [[ $a =~ one t.. three ]]; ...

I would say that since it *has* no legal syntax, currently, that it be
defined such that anything between the operators and the double sq brackets
be taken as a grouped expression == i.e. as though double quotes were 
around them.

That would solve the problem the problem consistently.

I.e. with square double brackets, then expressions on the right and left side
are always grouped as though they were in a variable.

It's unfortunate, that operations in double brackets, are not (or, were not) 
defined as communicative as they are in single brackets.  Was there a reason 
for that decision?  I.e.

	if [ me?t == me?t ] ; ... 
	
will match if meat is in the current directory,

but double brackets doesn't seem to work with globs on both sides of ==
(anymore than regexs do on either side of =~).

I was going to suggest some other quote operator to put around a regex, that 
would allow it to contain spaces, but symmetrically, it should also work around 
a glob rhs with ==.   But given that, currently

if [[ "xx yz" == xx * ]], has no current legal definition, any more than
if [[ "xx yz" =~ xx .* ]] has regex's, it seems reasonable to take anything
to either side of the operator up to a double bracket, as 1 expression with 
embedded spaces.

That would solve my issues with dquotes not being usable to group, and cause no 
backward portability problems.

-l