CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20

[Lenny Foner]

    Date: Tue, 24 Oct 2000 14:46:13 -0400 (EDT)
    From: address@hidden (Larry Jones)

    Derek R. Price writes:
    > 
    > I'm thinking maybe the standard test comes close to the argument length
    > limit and something about your system pushes it over the edge.

    On many systems, the environment counts against the maximum argument
    length limit; if you've got a lot of enviroment variables or some with
    very long definitions, try deleting them before running the tests.  (You
    may find env -i [some versions use - instead of -i] to be a handy way to
    do that.)

Ah ha!  This is -exactly- what the problem was.  I have somewhat over
300 environment variables (printenv returns about 11K bytes), since I
often point at useful parts of the filesystem with them.  (Do aliases
count as well?  What else?  Why isn't this -documented- anywhere?  Why
in the world is it -true-?  Even in GNU products?  Unheard-of!)

Rerunning the failing case with "env -i" prepended causes multiroot to
win (in either sh or bash), and I was able to then simply rerun the
entire test suite that way by simply saying "env -i sh ./sanity.sh
`pwd`/cvs".  It also runs to completion about 10% faster than it took
to fail (verified over various runs), which is interesting; I guess
that repeated recursive shell calls are doing less work w/a smaller
environment, or something.  Note that "env -i make check" in the src
dir worked, but not in the toplevel dir (where it would normally be
run), because for whatever reason the line in the makefile after
configuration only has an explicit path for some binaries:

            cd lib ; make AR='ar'  CC='gcc'  CFLAGS='-g -O2'  LDFLAGS=''  
LIBPROGS=''  LIBS='-lsec '  MAKE='make'  MAKEINFO='makeinfo'  RANLIB='ranlib'  
TEXI2DVI='texi2dvi'  YACC='bison -y'  bindir='/usr/local/bin'  
infodir='/usr/local/info'  libdir='/usr/local/lib'  mandir='/usr/local/man'  
prefix='/usr/local'  exec_prefix='/usr/local'
    expect 10 shift/reduce conflicts
            bison -y ./getdate.y
    Make: Cannot load bison.  Stop.
    *** Error exit code 1

I strongly suggest that "env -i" (or some suitably portable version
thereof) be used automatically by the Makefile when running "make
check".  Not only will this cause it to work when otherwise it fails,
but it removes a rather large source of potential variability in the
test results.  Why, after all, should we allow regression tests to be
run in an environment where user settings of various internationalization
environment variables might affect them?  (If we want to -test- such
settings, then that should be its own explicit test---and no, I
haven't checked sanity.sh to see what it may be doing with these.)  I
picked those variables because they are documented to change the
behavior of a large number of other tools, but who knows what other
environment variables might affect other random things.

And if some user is -depending- upon a particular environment
variable for things to work, then said user should have to add it
manually to the testing environment---rather than having everyone else
get a random set of things added to -their- testing environment that
they're not even aware of...

P.S.  Note that I am -not- advocating "env -i" during the build phase,
since that might potentially break many things.