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

[Pierre Gaston]

On Sun, Sep 19, 2010 at 2:54 AM, Linda Walsh <bash@tlinx.org> 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
> 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

Just quote the spaces and not the special chars:

[[ "xx yx" = 'xx  '* ]] or [[  "xx yz" = xx\ * ]]

or any other variation that escape or put the space inside quotes but
not the *

In the same way:  [[ "xx yz" =~ xx' '.* ]]

if you prefer to quote everything, use a helper variable:
regex='xx .*'
[[ "xx yz" =~ $regex ]]

No quotes, around the expansion, .* keeps its meaning, the space is
not a problem
as word splitting of the expansion doesn't occur inside [[ ]]
(This trick has the side effect of being backward compatible with bash3.1)

Note that the same problem and solution exist when you use filename generation:

for f in /some path/ withspaces/*; do  # doesn't work the path contains spaces
for f in "/some path/with spaces/*"; do # doesn't work * is not special anymore
for f in "/some path/with spaces/"* ;do # ok, spaces are quoted but not the *

The only difference is that since wordsplitting is occuring you cannot
use the variable trick
to quote everything:
glob='/some path/with spaces/*'
for f in $glob; do # fails the path is split into word
for f in "$glob";do # fails the * is quoted