[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Larry Jones
Subject: Re: CVS 1.11 fails at multiroot-log-1 under HPUX 10.20
Date: Wed, 25 Oct 2000 16:38:53 -0400 (EDT)

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

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

> 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 ./
> `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:

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!)  Note that you can preserve specific environment variables when
using env by adding them to the command:

        env -i PATH="$PATH" make check

-Larry Jones

I've changed my mind, Hobbes.  People are scum. -- Calvin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]