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

[Linda Walsh]

Pierre Gaston wrote:
what about:
> [[ foo =~ bar && baz ]]
>
> Should bar && baz be considered as one regexp? if not, how would you
> write a regexp matching
> `foo && baz' ? or `foo && baz.*' ? 
----
        Use parentheses to disambiguate ambiguous cases?



if yes how would you do and and
> with a regexp?
>
> What if you want to match `  bar && baz   ' with trailing or leading spaces?
----
        You'd be no worse off than you are now -- you'd have to use backslash
or some other quoting mechanism.  In my initial query on this issue, I
had [[ 'var' =~ multi word pattern ]].  I was only considering the case
where multiple words would generate a syntax error, currently, I hadn't
thought about the multi operator flavor.  

        Sounds like a simple rule might be to include words in the matching
string as long as they would not be ambiguous (would be a syntax error).  

        There's always plan B, but I was sorta resisting that...
        

> Space are used to separates arguments everywhere in the shell and yes
> quotes are sometimes
> ugly and often causes trouble until you take the time to learn to use
> them, but it's the price to
> pay to avoid putting quotes around every argument every time you use
> the command line interactively
---
The problem here, is there's no simple grouping operator that can go around regex's (and for that matter, globex's), that allow pattern matching (and expansion) within the grouping operator. 


> I don't see how your suggestion would help in the end since you would
> still need to quotes some chars like && or || and the handling of
> space would not be consistent with the rest of the shell.

	Unless you stopped the grouping when adding the next term has a 
legal interpretation.  The point of allowing multiple terms to be grouped 
as one expression was in the case where it would otherwise be interpreted 
as an error -- if there's a legal interpretation, as in your example above, then the rule would have to be that any currently legal interpretation 
remains that way and adding further terms wouldn't happen.

        Only in the case that adding further 'words' to the matching
expression would currently be illegal (generate some error), would 
grouping occur -- that way there would be no backward compatibility 
issues in currently working code.

	Plan B -- use some other quoting character to group the 
expression other than single or double quote.  There is one other type 
of quote that I know of that is sufficiently visually different from 
current symbols as to not be easily confused with any current 
operator -- the   « double angular »   quotation marks, (U+00AB, U+00BB).
I resist that idea only because my keyboard doesn't easily allow 
me to type them.  I suppose a [somewhat lame] substitute would be to
allow a multi-byte sequence like \<< \>> to be equivalent to the actual 
Unicode double-angular characters for use where the Unicode values
couldn't be used or were just too inconvenient.

        Since they are used in multiple latin-alphabet based languages
(french, spanish, swedish, et al), they shouldn't be too rare to be
found in western-language alphabet fonts.  The only other candidate, the
〝Double Prime〞 Quotation Marks (U+301D, U+301E), are in the CJK Punctuation
range, and would be less likely to be found in western-language fonts.

	Or, you could use a pair of a character like "/" (slash) 
around the expression as several other regex engines default to.
        
        If having a special case for multiple words on either side of
=~, **that would otherwise be illegal**,  seems odd -- I'd like to point
out inconsistent use of double quotes turning off expansion and of 
grouping, as in "$@" and "$*", respectively.

        Certainly the best option (under existing compatibility
constraints) might be to allow both -- multi-word grouping of otherwise
illegal terms, AND addition of the double-angular quote, that would
group an expression together but would still allow pattern substitution,
or matching, between them.

-l