Re: 18 csets coming up

[Jim Meyering]

Paolo Bonzini wrote:
> On 01/01/2010 04:48 PM, Jim Meyering wrote:
>> IMHO, the only one that deserves particular scrutiny is the last one:
>>
>>        maint: use regex from gnulib, rather than our bit-rotting one
>>
>> There have been almost no changes to the deleted files
>> since 2004, and those few appear to either already be
>> in the gnulib version, or are in parts that have been
>> completely rewritten.
>>
>> Of course, I've verified that all tests continue to pass.
>>
>> In the patches below, I've elided the large "remove this file"
>> parts of the "use regex from gnulib..." cset.
>
> Yeah, somehow it failed some tests when I tried it last November.  But
> if it works for you, all the better (of course I suppose you tried
> --without-included-regex ;-) ...).

Oh.  Shame on me.  I hadn't configured --with-included-regex.
Just did.  With it, there is only one failure:

    FAIL: spencer1.sh

It was #37:

When configured --with-included-regex:

    $ echo -|src/grep -E -e 'a[b-a]'
    src/grep: Invalid range end
    [Exit 2]

With F12's regex code:

    $ echo -|src/grep -E -e 'a[b-a]'
    [Exit 1]

I've included the trivial patch for that below.

The --with-included-regex behavior (exit 2, rather than 1) seems better,
since perl, awk, and sed also reject a regexp like [b-a].

However, this raises the issue that my modified test would now fail
when grep uses the system-supplied regex code from at least F12's libc.

I plan to adjust gl_REGEX (in gnulib) to reject the system
supplied code when it detects this behavior.  Does anyone object?
For the record, POSIX's A.9.3.5 RE Bracket Expression says:

    The ISO POSIX-2: 1993 standard required "[b-a]" to be an invalid
    expression in the POSIX locale, but this requirement has been relaxed
    in this version of the standard so that "[b-a]" can instead be treated
    as a valid expression that does not match any string.

This behavior is nominally controlled by the regexp flag,
RE_NO_EMPTY_RANGES, which is set in both basic and extended
POSIX regex syntax.

An alternative is to adjust the test situation so that it permits
an exit status of 1 or 2, but I dislike this approach.  We should
provide a consistent interface even in corner cases like this.

>From 2a324a512c6087ec7e52a84142d598151bfc1333 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Sat, 2 Jan 2010 18:43:22 +0100
Subject: [PATCH] tests: adjust spencer #37 to pass with gnulib's regex code

* tests/spencer1.tests: Change #37 to expect an exit status of 2, not 1.
grep 'a[b-a]' reports "Invalid range end".
---
 tests/spencer1.tests |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/spencer1.tests b/tests/spencer1.tests
index e382d42..b1aa78b 100644
--- a/tests/spencer1.tests
+++ b/tests/spencer1.tests
@@ -34,7 +34,7 @@
 address@hidden@aac
 address@hidden@a-
 address@hidden@a-
address@hidden@-
address@hidden@-
 address@hidden@-
 address@hidden@-
 address@hidden@a]
--
1.6.6.334.g442f

> Maybe it fixes some of the ugly -o and --color bugs (which are just
> the same bug).

That'd be a nice bonus.