Re: [platform-testers] [Grep-devel] new snapshot available: grep-2.25.92-f3e9

[Jim Meyering]

On Fri, Sep 16, 2016 at 1:47 PM, Eric Blake <address@hidden> wrote:
> On 09/15/2016 10:25 PM, Jim Meyering wrote:
>> We are nearly ready to make a new release, so here's a snapshot of the
>> latest. Please try it on any unusual system you can find and let us
>> know about any test failure (success is good to hear about, too).

Hi Eric,
Thank you for the testing and report.

> Building on 64-bit Cygwin 2.6.0 sees a warning fly by:
>
> make[3]: Entering directory '/home/eblake/grep-2.25.92-f3e9/lib'
> Makefile:1695: target '.deps/alloca.Po' given more than once in the same
> rule

There is an automake patch for that.
The problem is likely that I used an unpatched automake to generate
the Makefile.am files for this snapshot.

> but it appears harmless.  Then 'make check' fails the 'c-locale',
> 'fmbtest', and 'surrogate-pair' tests. More details, by looking at
> snippets of the log:
>
> c-locale:
> + tr2='\15'
> + echo X
> + tr X '\15'
> + LC_ALL=C
> + env -- tr X '\15'
> ++ wc -l
> + test 1 -eq 1
> + grep . in
> + fail=1
> + compare in out
> + compare_dev_null_ in out
> + test 2 = 2
> + test xin = x/dev/null
> + test xout = x/dev/null
> + return 2
> + case $? in
> + compare_ in out
> + diff -u in out
> --- in  2016-09-16 14:50:59.975484100 -0500
> +++ out 2016-09-16 14:50:59.975484100 -0500
> @@ -1 +0,0 @@
> -
> + fail=1
>
> Looks like carriage return is being mishandled somewhere; maybe
> something forgot to switch on binary mode and is treating \r\n
> identically to \n as in text mode.  May just be a Cygwin porting bug,
> rather than upstream.
>
> fmbtest, as viewed in 'less':
> +++ LC_ALL=cs_CZ.UTF-8
> +++ export LC_ALL
> +++ grep -Gi -e ČÍšE -e Čas csinput
> +++ sed 's/[^0123456789]/ /g'
> ++ echo 01 02 07 08 10 11 12 <95> <93>13 <93>14 <95> 15 16 <93>17 18 19
> <95> 20
> + test3='01 02 07 08 10 11 12 <95> <93>13 <93>14 <95> 15 16 <93>17 18 19
> <95> 20
> '
> + test '01 02 07 08 10 11 12 <95> <93>13 <93>14 <95> 15 16 <93>17 18 19
> <95> 20'
>  '!=' '01 02 07 08 10 11 12 13 14 15 16 17 18 19 20'
> + echo 'Test #3 G failed: 01 02 07 08 10 11 12 <95> <93>13 <93>14 <95> 15 16
> <93>17 18 19 <95> 20'
> Test #3 G failed: 01 02 07 08 10 11 12 <95> <93>13 <93>14 <95> 15 16
> <93>17 18 1
> 9 <95> 20
> + failures=1
>
> Hmm.  Could it be that sed is not converting '\x95' and '\x93' to
> spaces, at least in Cygwin's version of the cs_CZ.UTF-8 locale?  Testing
> further:
>
> $ printf 'a1\x952b\n' | sed 's/[^0123456789]/ /g' | od -tx1 -An
>  20 31 95 32 20 0a
>
> Weird. I'm not sure if the problem lies in sed proper, or in Cygwin's
> regex engine, but the failure is not directly due to grep.

Your example threw me for a minute. Confirmed the same thing happens
on fedora 24 with en_US:

  $ printf '\x95\n' >k; LC_ALL=en_US.UTF-8 sed 's/[^0-9]/ /g' k | od
-tx1 -An -ac
    95  0a
   nak  nl
   225  \n

Pretty sure \x95 is not a valid character (so conversion attempt
yields EILSEQ), so it is left unmodified. I note that perl -pe
's/[^0-9]/ /' works as one would expect.

> Finally, surrogate-pair, which is interesting since that test was
> written for Cygwin:
> + printf '\360\220\220\205\n'
> + LC_ALL=en_US.UTF-8
> + export LC_ALL
> + grep -i anything-else in
> + test 1 = 1
> + compare /dev/null out
> + compare_dev_null_ /dev/null out
> + test -s out
> + return 0
> + return 0
> + for opt in ''\'''\''' -i -E -F -iE -iF
> + grep --file=in in
> + fail=1
>
> Not sure why that is failing, or if it ever worked (we at least don't
> have the core dump mentioned in grep 2.14); but I'm also not sure if it
> is grep's fault.

I like the theme of "not grep's fault".