[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: coreutils-8.14.116-1e18d on AIX 5.1
From: |
Jim Meyering |
Subject: |
Re: coreutils-8.14.116-1e18d on AIX 5.1 |
Date: |
Thu, 05 Jan 2012 16:39:46 +0100 |
Bruno Haible wrote:
> Jim Meyering wrote:
>> > ERROR: misc/printenv
>> > ====================
>> >
>> > grep: Maximum line length of 2048 exceeded.
>> > grep: Maximum line length of 2048 exceeded.
>> > printenv: set-up failure:
>>
>> This appears to be due to the combination of your
>> environment containing a very long line and your using
>> a vendor grep that cannot handle that.
>
> Today, I cannot reproduce it any more, and the environment's lines
> are not longer than 128. Bizarre...
>
>> > FAIL: misc/timeout-parameters
>> > =============================
>> ...
>> > The expr command failed:
>> > $ /bin/expr 4294967295 / 86400 + 1
>> > 49711
>> > $ ../src/expr 4294967295 / 86400 + 1
>> > ../src/expr: 4294967295: A return value of a math subroutine is not within
>> > machine precision.
>> >
>> > This error comes from expr.c:478.
>> >
>> > Is 'expr' required to recognize integers outside of the 'int' range?
>>
>> Yes, if you build coreutils with libgmp.
>>
>> > If yes: bug in 'expr'. If no: bug in the test.
>>
>> Yes, ideally, the test would not rely on expr being built with libgmp.
>
> But even an 'expr' built without libgmp should work fine with integers up to
> 2^63, since expr.c uses 'intmax_t'. Here it is failing to parse a 32-bit
> integer, due to a bug in the strtoimax() function in libc.
Oh, right. yet another libc bug.
>> > FAIL: misc/tr
>> > =============
>> > tr: test bs-at-end.r: stderr mismatch, comparing bs-at-end.r.E (actual) and
>> > bs-at-end.r.3 (expected)
>> > *** bs-at-end.r.E Wed Jan 4 22:31:17 2012
>> > --- bs-at-end.r.3 Wed Jan 4 22:31:17 2012
>> > ***************
>> > *** 0 ****
>> > --- 1 ----
>> > + tr: warning: an unescaped backslash at end of string is not portable
>> > tr: test bs-at-end.p: stderr mismatch, comparing bs-at-end.p.E (actual) and
>> > bs-at-end.p.3 (expected)
>> > *** bs-at-end.p.E Wed Jan 4 22:31:17 2012
>> > --- bs-at-end.p.3 Wed Jan 4 22:31:17 2012
>> > ***************
>> > *** 0 ****
>> > --- 1 ----
>> > + tr: warning: an unescaped backslash at end of string is not portable
>>
>> Odd. Please rerun that test as follows:
>>
>> make check -C tests TESTS=misc/tr VERBOSE=yes DEBUG=yes
>>
>> and then look at the file, tests/misc/tr.log.
>> I see this:
>>
>> creating file `bs-at-end.p.1' with contents `\'
>> creating file `bs-at-end.p.2' with contents `x'
>> creating file `bs-at-end.p.3' with contents `tr: warning: an unescaped
>> backslash at end of string is not portable
>> '
>> bs-at-end.p...
>> Running command: `cat 'bs-at-end.p.1' | tr '\' x > bs-at-end.p.O 2>
>> bs-at-end.p.E'
> Running command: `cat 'bs-at-end.p.1' | tr '\\' x > bs-at-end.p.O 2>
bs-at-end.p.E'
There's the difference.
Somehow it's running tr with the wrong argument, '\\' rather than '\'.
> tr: test bs-at-end.p: stderr mismatch, comparing bs-at-end.p.E
> (actual) and bs-at-end.p.3 (expected)
> *** bs-at-end.p.E Thu Jan 5 15:13:31 2012
> --- bs-at-end.p.3 Thu Jan 5 15:13:31 2012
> ***************
> *** 0 ****
> --- 1 ----
> + tr: warning: an unescaped backslash at end of string is not portable
>
> The behaviour of the 'tr' program is consistent with what I seen on a glibc
> system:
>
> $ echo | LC_ALL=C ./tr '\' x
> ./tr: warning: an unescaped backslash at end of string is not portable
>
> $ echo | LC_ALL=C ./tr '\\' x
>
> It might be a problem in perl? perl version is 5.6.0.
Could be...
But probably not worth pursuing.