On 09/01/2010 08:09 AM, Paolo Bonzini wrote:
On 09/01/2010 04:01 PM, Jim Meyering wrote:
Do you honestly imagine
http://opengroup.org/onlinepubs/007908775/xbd/re.html changed to say
"If a bracket expression consists of a colon, a series of alphabetic
characters, and another colon, the implementation's behavior is
undefined?
Perhaps that is where we disagree, then.
I do not require that POSIX allow the new behavior.
That may be it. In particular, I think for something that POSIX is
unlikely to aver allow, there should be another way than POSIXLY_CORRECT
to disable it.
Personally, I'd _like_ to try to get POSIX to allow unspecified behavior
for a bracket expression that starts and ends with colon, at which
point, we could then drop the POSIXLY_CORRECT notion, and blindly reject
[:upper:]. In fact, I'm going to go create that aardvark today (link to
follow soon...)
But I'm happy with Jim's approach - to treat it as the valid regex which
it is under current POSIX rules, set POSIXLY_CORRECT; otherwise, since
it is so likely to be wrong, treat it as an error, and hope that POSIX
will change to agree someday.
Ranges like [A-Z] are so common that changing the default
would have far-reaching effects. Will it ever be possible?
I don't know. Perhaps if we first allow it to be enabled via
some new environment variable, and then, much later, make it the default.
/me whispers --warn...
I also see the value of adding a --warn parameter, to fine-tune how much
warning is issued, and whether warnings are fatal. But I'm also just
fine waiting until we have more implementation experience (how often
does the current warning trigger, what other expressions are worth
warning about, and what does the Austin Group say about my proposed
change to BRE and ERE bracket expressions). In the meantime, not having
a --warn is workable; I'm certainly not missing the fine-tune knob yet
in my own usage patterns of grep.
--
Eric Blake [email protected] +1-801-349-2682
Libvirt virtualization library http://libvirt.org
