[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Linda Walsh
Subject: Re: RFE: request for quotes as grouping operators to work in brackets as elsewhere.
Date: Mon, 20 Sep 2010 23:45:10 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Thunderbird/ Mnenhy/

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]