coreutils
[Top][All Lists]
Advanced

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



reply via email to

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