|
From: | Eric Blake |
Subject: | sed issue? [was: Subject: [GNU Autoconf 2.67] testsuite: 233 failed] |
Date: | Mon, 20 Sep 2010 18:34:23 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.3 |
On 09/20/2010 04:32 PM, Eric Blake wrote:
I managed to get on a Darwin machine (MacOS X 10.5.5), and reproduced your failure: +allowed-chars Zardoz differ: char 168, line 2 ./torture.at:937: exit code was 1, expected 0 I'm now looking into it further, first by trying to see if it is still present in the latest autoconf.git.
Yes, the problem is still present in the latest autoconf.git. It appears to be that we are triggering some sort of locale-specific bug in GNU sed, and that for some reason, using LC_ALL=C on Darwin is not enough to avoid that bug.
I'm attaching some files pruned from the test, and hoping that they don't get corrupted during mailing since they include some 8-bit bytes.
On my Fedora box, with sed 4.2.1, I see different behavior for: $ LC_ALL=en_US.UTF-8 sed -f file.sed file.awk > out1 $ LC_ALL=C sed -f file.sed file.awk > out2Where the behavior of out2 is what configure must use in order to generate a valid config.status for the funky contents of the shell variable $zardoz. But on Darwin, even with LC_ALL=C, I'm getting the out1 behavior, which leads to a broken config.status.
Maybe the sed script in file.sed is non-portable? It's certainly more complex than the normal run-of-the-mill sed script. Or maybe it is that the regex '.' has problems matching non-characters, and the definition of the various locales determine whether 8-bit bytes are characters or not. Is there any portable way to guarantee a single-byte locale where '.' matches all possible 8-bit bytes?
-- Eric Blake address@hidden +1-801-349-2682 Libvirt virtualization library http://libvirt.org
file.awk
Description: Binary data
file.sed
Description: Text document
out1
Description: Binary data
out2
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |