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