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

[Tim Mooney]

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