Re: coreutils-8.14.116-1e18d on AIX 5.1

[Jim Meyering]

Bruno Haible wrote:
>>   http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz
>
> On AIX 5.1, there are 1 framework failure and 5 test failures.

Thanks for the report!

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

I suggest you take this as a hint to install GNU grep.
I.e., I think failing this test is the proper response.

> FAIL: rm/unread3
> ================
> rm: unable to record current working directory: Too many open files
> rm: unable to record current working directory: Too many open files

I might debug it if I had access to such a system.
On the other hand, I get the impression that there are so few AIX 5.x
systems around and in actual use that it's probably not worth it.
Besides, they're probably (due to lack of openat-etc. support) using
the save-cwd emulation layer, which few systems use these days.

Given the fundamental failures reflected in this report,
what do you think about removing AIX 5.1 from gnulib's list of
reasonable portability targets?


> FAIL: misc/printf
> =================
...
as you say, this fails due to vendor libc

> FAIL: misc/printf-cov
> =====================
...
Likewise

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

> 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'

Note that the actual command it runs is tr '\\' ...
The "'\'" is probably just an artifact of how the debugging output is printed.