platform-testers
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: [platform-testers] new snapshot available: grep-2.25.92-f3e9
Date: Fri, 16 Sep 2016 15:47:36 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

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).
> 

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

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.


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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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