[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11256: make check problems with coreutils 8.16 and earlier
From: |
Tim Mooney |
Subject: |
bug#11256: make check problems with coreutils 8.16 and earlier |
Date: |
Thu, 19 Apr 2012 11:22:59 -0500 (CDT) |
User-agent: |
Alpine 2.02 (SOC 1266 2009-07-14) |
In regard to: Re: bug#11256: make check problems with coreutils 8.16 and...:
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.
:-) Oh come on, my environment isn't *that* unusual.
I'm not sure if we'll work around your two remaining test failures.
Understood.
The ERROR looks like it's due to an exported "grep" function.
Close, but not quite:
10:59 AM dogbert ~$type -a grep
grep is aliased to `egrep'
grep is /usr/xpg4/bin/grep
grep is /usr/bin/grep
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
Again close:
10:59 AM dogbert ~$type -a date
date is aliased to `date "+%a %e %b %r"'
date is /usr/xpg4/bin/date
date is /usr/bin/date
date is /local/gnu/bin/date
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 ;-)
;-) I'm surprised more people aren't impacted by "convenience" aliases,
but I would imagine that most people don't build coreutils themselves,
they don't run the test suite, or if they do both, then it's a vendor
that has a carefully-limited build environment.
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.
It's an alias rather than a function, but otherwise you're spot-on.
Don't do that. If you export anything, it should be the other way
around, mapping uses of the obsolescent "egrep" to "grep -E".
The issue is one of portability. In your case, I'm sure that every
plaform you care about has a grep that supports -E, but in my case, that's
not true. My environment is set such that if I have any version of bash
available, I can copy my shell startup files to about any flavor of UNIX
you can imagine and the aliases and other settings are going to "smooth out"
the differences. I don't even require that coreutils or its predecessors
be installed -- eventually I would want them installed, but if I'm called
in to work on a UNIX box, I want an environment that's going to work and
help me be productive right away, until I can get all the good stuff
installed.
I had no idea "egrep" was obsolescent.
Regarding the overall issue of environment: One thing that would help
would be to enhance configure's search for a POSIX shell, so that if it
finds bash as the POSIX shell, it automatically includes "--norc" when
executing the tests.
If you have any interest in it, I would consider supply a patch against
the tests that checks to see if the invoking shell is bash, and if it is,
it just runs "unalias -a" at the start of the test.
Tim
--
Tim Mooney address@hidden
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164