bug#11256: make check problems with coreutils 8.16 and earlier

[Jim Meyering]

Tim Mooney wrote:
> In regard to: Re: bug#11256: make check problems with coreutils 8.16 and...:
>
>>> I have confirmed that if I do
>>>
>>>     gmake check VERBOSE=yes SHELL=/usr/xpg4/bin/sh
>>>
>>> then the tests perform as expected -- I get four failures and one
>>> error and quite a number of skips, but no issues with tests hanging
>>> because it's the OS version of the command being run:
...
>>> So, the problem appears to be that the test cases aren't sufficiently
>>> insulated from the user's environment.
>>
>> Indeed.  Please send the file, tests/test-suite.log, which
>> contains details of which tests failed and how.
...
>    GNU coreutils 8.16: tests/test-suite.log
> ==============================================
...
> # FAIL:  3
> # ERROR: 1

Thanks.

Here's a summary:

Of the three FAILed tests, one is a test suite bug that has
already been fixed and the other two are due to your unusual environment.
I'm not sure if we'll work around your two remaining test failures.
See below.

The ERROR looks like it's due to an exported "grep" function.

...
> FAIL: misc/date-sec
> ===================
...
> + env date --version
> date (GNU coreutils) 8.16
...
> + n=0
> ++ date '+%a %e %b %r' +%S
> date: extra operand '+%S'
> Try 'date --help' for more information.
> + s=
> + case "$s" in
> + test 0 = 0
> ++ date '+%a %e %b %r' '--date=21:04 +0100' +%S
> date: extra operand '+%S'
> Try 'date --help' for more information.

That is because you use bash, you've defined your own incompatible
date function and you've exported it:

    $ date() { echo foo; }
    $ export -f date
    $ date
    foo
    $ bash -c date
    foo

Oddly, with GNU bash, version 4.2.24(1)-release (x86_64-redhat-linux-gnu)
"export -fn date" does not "unexport" the date function.
Hence, since I see no way to undo your setting and
I don't want to insert an "env " prefix in every shell-based
test, I suggest that you stop exporting that function.
Besides, in all of these years, you're the only one to
have provoked this failure ;-)

> FAIL: misc/expr
> ===============
>
> expr: 9758060798730154302876482828124348356960410232492450771490: Result too 
> large
> expr (GNU coreutils) 8.16
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Mike Parker, James Youngman, and Paul Eggert.
...
> bre49...
> expr: test bre49: stderr mismatch, comparing bre49.E (actual) and bre49.1 
> (expected)
> *** bre49.E   Tue Apr 17 16:58:37 2012
> --- bre49.1   Tue Apr 17 16:58:37 2012
> ***************
> *** 1 ****
> ! expr: Regular expression too big
> --- 1 ----
> ! expr: Invalid content of \{\}

That was fixed post-release by this change:

    http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=0f35329876580f0
    tests: avoid spurious misc/expr failure on AIX 6.1
    * tests/misc/expr: Avoid spurious failure on AIX 6.1 due to
    differing regexp diagnostic.  Reported by Michael Felt.

...

> FAIL: split/filter
> ==================
...
> + rm -f in
> + split -e -n 10 '--filter=xz > $FILE.xz' /dev/null
> + stat 'x??'
> + split -n 1/2 --filter=true /dev/null
> + yes
> + head -n200K
> + split -b1G '--filter=head -c1 >/dev/null'
> head: illegal option -- c
> split: with FILE=xaa, exit 1 from command: head -c1 >/dev/null
> + fail=1
> + timeout 10 yes
> + split '--filter=head -c1 >/dev/null' -n r/1
> head: illegal option -- c
> split: with FILE=xaa, exit 1 from command: head -c1 >/dev/null
> + fail=1
> + timeout 10 split '--filter=head -c1 >/dev/null' -n 1 /dev/zero
> head: illegal option -- c
> split: with FILE=xaa, exit 1 from command: head -c1 >/dev/null

The split/head problem appears to be due to your unorthodox (aka bogus ;-)
PATH setting.  split's subshell ends up with a PATH setting that is so
different that it cannot find the just-built "head" binary that this
test requires.

I'm not sure it's worth trying to work around that sort of problem.

> ERROR: misc/printenv
> ====================
...
> + env printenv --version
> printenv (GNU coreutils) 8.16
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by David MacKenzie and Richard Mlynarik.
> + env
> + egrep -Ev '^(_|LD_PRELOAD=)'
> Usage:        egrep [-c|-l|-q] [-bhinsvx] pattern_list [file ...]
>       egrep [-c|-l|-q] [-bhinsvx] [-e pattern_list]... [-f pattern_file]... 
> [file...]
> + framework_failure_
> + warn_ 'printenv: set-up failure: '

The code I see in the test script does this:

    env | grep -Ev '^(_|LD_PRELOAD=)' > exp || framework_failure_
    env -- printenv | grep -Ev '^(_|LD_PRELOAD=)' > out || fail=1
    compare exp out || fail=1

I.e., no use of "egrep".
I have to conclude that you have an exported grep function that runs egrep.
Don't do that.  If you export anything, it should be the other way
around, mapping uses of the obsolescent "egrep" to "grep -E".