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

[Larry Jones]

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

Yes, this is way off-topic, but the short story is that the kernel only
deals with one process at a time, so in order to copy the argument list
and environment from the parent process to the child, it first copies it
from the parent into a fixed-size temporary area in the kernel and then
copies it from there to the child.

> 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.
[...]
> Anyway, changing it just for the sake of making a marginal
> case in CVS' test suite work is unlikely to happen...

Indeed.  It's just that such a large environment is likely to cause you
similar problems in other circumstances (``ls *'' in a large directory,
for example), so I thought it was worth mentioning.

> 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.

That's a red herring (actually two red herrings).  path is treated
specially by most csh-like shells and automagically exported (as PATH)
reguardless of how you set it.  Also, the expansion of $PATH in the
above command is done by the shell *before env even runs* -- running
``env -i printenv'' will show that the child process really does have an
empty environment; running ``env -i tcsh -c set'' will show the default
values tcsh makes up for things like path when they aren't inherited.

> 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.

They aren't random -- there's a well-defined set that the test suite
uses if they're set:

        TESTDIR - the directory to run the tests in
        AWK     - the awk program to use
        EXPR    - the expr program to use
        ID      - the id program to use
        TR      - the tr program to use

All of them have default values, but they are not appropriate for some
people.  (Note that these affect only the test suite itself, not CVS, so
there's no danger of CVS working for the tester but not for the users
based on their settings.)  These variables exist because people (plural)
have needed them -- you're the very first person to report a problem
running the tests because of a large environment.

-Larry Jones

I like maxims that don't encourage behavior modification. -- Calvin