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

[Lenny Foner]

    Date: Wed, 25 Oct 2000 16:38:53 -0400 (EDT)
    From: address@hidden (Larry Jones)

    Lenny Foner writes:
    > 
    > 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!)

    Aliases don't count unless they're exported into the environment

Well, this is tcsh, so there isn't really a distinction there...

    (they're usually not -- check your shell documentation for details).  It
    probably is documented somewhere, but it can be hard to find; try the
    exec*, errno, and intro(2) man pages.  It's a kernel limit so it's out
    of GNU's control -- many times there's a kernel configuration variable
    to adjust it, but I don't know any details for HP-UX.

Okay, I have -no- idea why the kernel cares about any of this.  I had
the impression that all of this was user-space stuff.  I guess that
exec and friends are passing the information to the newly-started
process in ways I wasn't expecting, and it's probably time I took a
closer look at them---though this is really a side-issue here.

    If you only use your variables in interactive shell commands (which it
    sounds like you do) there's no reason for them to be in the environment
    -- just set them and don't export them (or use set instead of setenv if
    you're a csh user).

I'm reasonably sure I had reasons for these being setenvs and not
sets, having to do probably w/the ability for Emacs to inherit them
from the shell I started it from, but I don't recall.  It's been a
very long time (years) since I set up the skeleton of what's become my
environment, and there may well be multiple reasons.  (And I know that
some of them are deliberate set/setenv based on whether or not I want
them bleeding into subshells, etc.  It's gotten quite complicated over
the years.)  Anyway, changing it just for the sake of making a marginal
case in CVS' test suite work is unlikely to happen...

    [ . . . ]
    > 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:

    That's because those binaries live in different places on different
    systems but they're almost always on the user's path.  And that's what
    makes it tricky to prune the environment automatically -- there are a
    number of environment variables that you *do* want to keep, but only
    *you* know for sure what they are.  (Although PATH is a pretty good
    bet!)  [ . . . ]

Well...  my $PATH is actually set using "set path", not "setenv PATH",
which means that "env -i echo $PATH" actually returns a non-null path.
(But I think this is treated very specially by tcsh; again, I don't
recall the details.)  Presumably, the fact that "env -i echo $PATH" is
non-null explains, in part, why "make check" while in cvs-1.11/src
worked, but in that case, I don't understand why "env -i make check"
-at toplevel- (e.g., not inside src) then blew up with what looks like
a missing-PATH problem.  I haven't debugged this at all, though.  I
have a suspicion it may have to do w/recursive calls to make.

But anyway, for "make check" alone, wouldn't it make sense to just
zero the environment?  I can't see why it would depend on some random
set of user EV's---that seems extremely undisciplined for a test
suite.  And it certainly worked fine for -me- with a zeroed
environment, not that this tells us much about other systems.
(Not to mention that, if weird EV's -are- used, wouldn't it be a
-really good idea- to have the test suite explicitly know what they
are?  After all, if you don't do this, then you run the risk of the
suite working fine in the builder/tester's environment, but CVS
malfunctioning in other users' environments, which is a disaster
that's also problematic to debug.  Better that it blow up while being
built, so the builder knows to adjust all users' environments if
necessary, rather than having it possibly be weird only for some of
the users.)