CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
A completely normal ./configure; make; make check just failed: /bin/sh ./sanity.sh `pwd`/cvs This test should produce no other output than this line, and a final "OK". ./sanity.sh[22]: /usr/local/bin/expr: The parameter list is too long. ./sanity.sh[29]: /usr/local/bin/expr: The parameter list is too long. FAIL: multiroot-log-1 make[1]: *** [check] Error 1 make[1]: Leaving directory `/usr/local/src/cvs-1.11/src' make: *** [check] Error 2 This is 94% of the way through sanity.sh, and I assume is because my expr or my shell is deficient. I get "expr (GNU sh-utils) 1.16" from expr --version, and my shell, while lacking any easy way to determine its version, at least says this: > strings /bin/sh | grep -i version @(#) Version M-11/16/88f (On both HPUX 10.20's I just looked at, /bin/posix/sh is just a symlink to /bin/sh; under 9.x, it used to be that /bin/posix/sh handled long arglists better. Under 10.20, who knows.) I'm willing to believe that CVS itself is working fine, but it'd be nice to have sanity tests that don't stress everything else so hard that I can't get through them. Any suggestions? Btw, sanity.sh ran for about 40 minutes on this 735/100 before it blew up. 1.9's sanity ran about 10 minutes, and I haven't tried 1.10 on this platform---but 1.11's is 4x as long as 1.9's, so that's just about the right timing... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Some more details about this failure, and suggestions for developers: It's really unclear to me whether this problem is genuinely that expr can't cope with the expression, or if it's some interaction with the shell. I get a different error message with a different shell: > /usr/local/bin/bash ./sanity.sh `pwd`/cvs This test should produce no other output than this line, and a final "OK". ./sanity.sh: /usr/local/bin/expr: Arg list too long ./sanity.sh: /usr/local/bin/expr: Arg list too long FAIL: multiroot-log-1 > /usr/local/bin/bash -version GNU bash, version 1.14.0(1) ...but the same behavior. Of course, this could just be different reporting of the same returned error code from expr. I also tried renaming /bin/sh out of the way and then symlinking /bin/sh to /usr/local/bin/bash, just in case there was some recursive call that was still using /bin/sh. This did not change the behavior. So. It looks like this fails using GNU expr -and- GNU bash. Why does it work on, e.g., GNU/Linux? (I -assume- we'd be hearing about it if sanity.sh didn't work in most places, or do most people not run the tests?) I'm really surprised to see this---a cursory examination of expr.c doesn't reveal any hard-coded limits (and its manpage is silent about this), and GNU products in general are very good about avoiding them. So what's really going on here? SUGGESTIONS FOR DEVELOPERS (I'm probably not going to act on these): (1) Make sanity.sh have a mode that prints all paths & binaries, so you can figure out how -it- thinks the system is configured--- since it does a lot of second-guessing, the alternative forces the poor user to edit the script to echo various variables in order to verify that the "right" versions of things are running. Make sure that there's a big comment at the front showing what command-line arg to use to invoke it. (While you're there, take the current usage comment and make it a -lot- more visible---maybe surround it with a sea of asterisks? I missed it about 10 times, because it was completely buried right after the copyright notice, with nothing in particular to make it stand out. And that usage line could use some clarification, too; it's not obvious that "cvs-to-test" is actually "directory in which to put our temporary files" without already knowing how the Makefile calls it.) (2) Make it easier (somehow) to figure out which test to resume at when one fails. I see that sanity.sh allows one to specify a particular test to run---it's a command-line argument---but there is no easy way to figure out what to put there. It requires a careful reading of that -enormous- loop to figure out which branch corresponds to individual dotests; I basically looked at the list of test groups at the front and guessed that "multiroot" was the right test for multiroot-log-1. If I'd guessed wrong, I'd have had to try all the other multiroots, etc, because scanning backwards through a very cluttered bunch of code to find something like "multiroot)" hanging out is painful. (Perhaps I could have done a reverse-regexp-search---but I shouldn't -have- to). Some sort of logic that automatically built the correspondence between dotests & those branches would be good (and then have the FAIL message tell you which test exactly you should specify to a later sanity run, since typing in the name of the test printed in the FAIL will -not- work). (3) Allow running all tests -after- a particular failing test; this at least allows the -rest- of them to be easily run, even if some particular test is obstinate. If this failure had happened 1% of the way in, I'd be looking at running sanity.sh by hand on every single test after that, and that's a lot of work. (4) Perhaps have sanity.sh check for shell limits at the start, and whine at the user if it runs into them---perhaps also attempting to use bash if sh seems insufficient, using the same sort of logic that attempts to use GNU expr if the vendor-supplied version seems broken. Obviously, sanity.sh would therefore simply call itself recursively w/the new, hopefully-better shell, althogh care should be taken to avoid infinite loops. [Again, I don't know if -my- particular failure is the shell or expr, but this might help somebody.] (5) Change the test code to not rely on such enormous strings. It's clear that they provoke malfunctions on at least one platform that presumably have nothing to do with CVS itself. Given that this doesn't even work with GNU bash & expr, I'm currently stuck. All I can do is hope that CVS itself actually works, even though it fails its regression tests. It -did- get 94% of the way through them, which is encouraging. Original traffic, for reference: Date: 22 Oct 2000 09:30:06 +0100 From: James Youngman <[EMAIL PROTECTED]> Lenny Foner <[
CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Date: Tue, 24 Oct 2000 14:46:13 -0400 (EDT) From: [EMAIL PROTECTED] (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. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Date: Wed, 25 Oct 2000 16:38:53 -0400 (EDT) From: [EMAIL PROTECTED] (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.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Lenny Foner <[EMAIL PROTECTED]> writes:
> A completely normal ./configure; make; make check just failed:
>
> /bin/sh ./sanity.sh `pwd`/cvs
> This test should produce no other output than this line, and a final "OK".
> ./sanity.sh[22]: /usr/local/bin/expr: The parameter list is too long.
> ./sanity.sh[29]: /usr/local/bin/expr: The parameter list is too long.
> FAIL: multiroot-log-1
> make[1]: *** [check] Error 1
> make[1]: Leaving directory `/usr/local/src/cvs-1.11/src'
> make: *** [check] Error 2
>
> This is 94% of the way through sanity.sh, and I assume is because my
> expr or my shell is deficient.
This test does something broadly similar to :-
arg="some ...
... very ...
... long string ...
"
if test -z "$arg"
then
else
echo "$arg" > ${TESTDIR}/dotest.tmp
if $EXPR "`cat ${TESTDIR}/dotest.tmp`" : \
"$arg"${ENDANCHOR} >/dev/null; then
fi
fi
So, the expr command is no the first usage of the very long string,
but the expr command does include a few characters more than the
actual argument.
Sadly, the only way I can think of to make this test work on a vanilla
HPUX system is to carge up the output with sed(1) and match it in
pieces, which is nontrivial. The only way I can think of to do this
otherwise is to make a program which implements variant on expr's ":"
operator, but reads the expression from a file (thus getting round
command-length limits).
FWIW, I had a look at sanity.sh just now and noticed a typo. This
version of sanity.sh is something I checked out of CVS some time back,
so the line numbers are likely to be off.
--- sanity.sh.old Sun Oct 22 09:17:38 2000
+++ sanity.sh Sun Oct 22 09:17:57 2000
@@ -159,7 +159,7 @@
find_tool ()
{
- GLOCS="`echo $PATH | sed 's/:/ /g'` /usr/local/bin /usr/contrib/bin /usr/gnu/bin
/local/bin /local/gnu/bin /gun/bin"
+ GLOCS="`echo $PATH | sed 's/:/ /g'` /usr/local/bin /usr/contrib/bin /usr/gnu/bin
+/local/bin /local/gnu/bin /gnu/bin"
TOOL=""
for path in $GLOCS ; do
if test -x $path/g$1 ; then
--
James Youngman
Manchester, UK. +44 161 226 7339
PGP (GPG) key ID for <[EMAIL PROTECTED]> is 64A95EE5 (F1B83152).
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
James Youngman wrote: > FWIW, I had a look at sanity.sh just now and noticed a typo. This > version of sanity.sh is something I checked out of CVS some time back, > so the line numbers are likely to be off. Checked in. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Any sufficiently perverted technology is indistinguishable from Perl. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Lenny Foner wrote: > It's really unclear to me whether this problem is genuinely that expr > can't cope with the expression, or if it's some interaction with the > shell. I get a different error message with a different shell: > > /usr/local/bin/bash ./sanity.sh `pwd`/cvs > This test should produce no other output than this line, and a final "OK". > ./sanity.sh: /usr/local/bin/expr: Arg list too long > ./sanity.sh: /usr/local/bin/expr: Arg list too long > FAIL: multiroot-log-1 > > /usr/local/bin/bash -version > GNU bash, version 1.14.0(1) > ...but the same behavior. Of course, this could just be different > reporting of the same returned error code from expr. CVS was passing nightly regression tests on HP-UX 10.20 for the 1.11 release and still is. I'm thinking maybe the standard test comes close to the argument length limit and something about your system pushes it over the edge. Glancing through the offending test, a longer than normal user name seems the most likely culprit. Other possibilities include a longer than normal $TESTDIR. If you suspect the user name then setting $TESTDIR to something shorter and rerunning the tests might fix the problem easier than changing your username. e.g. TESTDIR=/tmp/1 make check && TESTDIR=/tmp/1 make remotecheck Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Take my advice, I don't use it anyway. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
James Youngman wrote: > Sadly, the only way I can think of to make this test work on a vanilla > HPUX system is to carge up the output with sed(1) and match it in > pieces, which is nontrivial. The only way I can think of to do this > otherwise is to make a program which implements variant on expr's ":" > operator, but reads the expression from a file (thus getting round > command-length limits). It seemed non-trivial to me too. Then a moment of inspiration allowed me to shorten the script, though it only works if there is a one-to-one correspondance between line in the expr and the text (i.e. .* will no longer match '\n', but I think this is all that is usually, if not always, necessary for the current gamut of tests). Anyway, it would need to be adapted for use directly by sanity.sh, but I just checked debug_check_log.sh into contrib in case anybody is interested in doing the work. What basically needs to be done is that an eval_line_by_line function needs to be ported into sanity.sh. Then that function can be called on the output of any failed test for more useful output. It could also be wrapped to create a dotest_line_by_line that almost works (see '\n' notes above) and could be used on inordinately long tests, such as multiroot-log-1, one when necessary. Incidentally, this dotest_line_by_line should make it trivial to write a sanity.sh that works with the Solaris version of expr, assuming my assumption about few of the tests requiring .* to match a line feed is correct. I should get around to writing this eventually if no one else does. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- They are laughing at me, not with me. They are laughing at me, not with me. They are laughing at me, not with me... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
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.) -Larry Jones Why is it you always rip your pants on the day everyone has to demonstrate a math problem at the chalkboard? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
On Tue, Oct 24, 2000 at 02:46:13PM -0400, Larry Jones wrote: > 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.) Should the sanity test cases do that by default? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Mike Castle wrote: > On Tue, Oct 24, 2000 at 02:46:13PM -0400, Larry Jones wrote: > > 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.) > > Should the sanity test cases do that by default? Not sure. At the least you'd have to worry about either getting a few variables like TESTDIR, AWK, & CVS_RSH into the test script itself past your 'env -i' bootstrap or bury the 'env -i' call in the do_test's and then make sure you get CVS_RSH & c. into the individual calls to CVS. The bootstrap method would probably be more robust since some of the tests call external functions directly then call 'pass' or 'fail' based on $?. It's possible you'd also have to make exceptions to pass through variables which configure awk, sed, diff, troff, and any other tools used by sanity.sh, but maybe not as sanity.sh already overrides variables like LC_ALL to insure uniformity of operation across platforms. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Pi R squared?!?! Nooo! Pie R round, cornbread R square! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
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 ./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: 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
At 10:57 -0400 10/26/00, Larry Jones wrote: > >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. Maybe it would be safer to clear the environment at the beginning of sanity.sh. This is what I have used in the past to clear out unwanted stuff inside of a script. #! /bin/sh for VAR in `set | /usr/bin/sed -e 's/=.*//'`; do case $VAR in PATH ) ;; IFS ) ;; SHELL ) ;; USER ) ;; PS1 ) ;; PS2 ) ;; MAILCHECK ) ;; OPTIND );; * ) unset $VAR; export $VAR;; esac done unset VAR PATH=/usr/bin export PATH Modify it as you see fit and put it at the beginning of sanity.sh. Fred -- == Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Frederic Brehm writes: > > This is what I have used in the past to clear out unwanted stuff > inside of a script. Unfortunately, unset isn't portable. I just don't see this as being a serious enough problem to worry about. -Larry Jones We don't ATTEND parties, we just CRASH 'em. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
> Unfortunately, unset isn't portable. I just don't see this as being a > serious enough problem to worry about. Oh c'mon. A portable fix for a confusing problem area is very simple: env |sed -e 's/=.*'/=/' >/tmp/clean$$ for V in PATH HOME TR AWK ... ; do eval "save$V=$V" done . /tmp/clean$$ for V in PATH HOME TR AWK ... do eval "$V=save$V ; export $V" done Save the env vars sanity cares about, then by definition you don't care what values the other env vars are. :) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Derek R. Price writes: > > What basically needs to be done is that an eval_line_by_line function needs to be >ported into sanity.sh. Then that > function can be called on the output of any failed test for more useful output. It >could also be wrapped to create a > dotest_line_by_line that almost works (see '\n' notes above) and could be used on >inordinately long tests, such as > multiroot-log-1, one when necessary. Incidentally, this dotest_line_by_line should >make it trivial to write a sanity.sh > that works with the Solaris version of expr, assuming my assumption about few of the >tests requiring .* to match a line > feed is correct. Note that sanity.sh already contains a dotest_line_by_line function. It's used by dotest_internal_debug, which is a plug-compatible replacement for dotest_internal that can be used for debugging (it's significantly slower, which is why it isn't used by default). While there aren't a lot of tests that need .* to match newline, I think there are more than a few. -Larry Jones I've got more brains than I know what to do with. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Larry Jones wrote: > Note that sanity.sh already contains a dotest_line_by_line function. > It's used by dotest_internal_debug, which is a plug-compatible > replacement for dotest_internal that can be used for debugging (it's Yeah, but I spent an hour or two trying to get it to work and had trouble. Besides, I was annoyed at having to edit sanity.sh to debug it in the first place, so I wrote the external version. I'll see if I can make the contraption automatic later. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- He who dies with the most toys, is, nonetheless, still dead. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Derek R. Price writes:
>
> Yeah, but I spent an hour or two trying to get it to work and had trouble.
I can't imagine why -- all you have to do is change some or all of the
calls to dotest_internal to dotest_internal_debug instead. Except for
tests where ${DOTSTAR} is supposed to match multiple lines, it just
works.
-Larry Jones
Do you think God lets you plea bargain? -- Calvin
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Lenny Foner <[EMAIL PROTECTED]> writes:
> Date: Tue, 24 Oct 2000 14:46:13 -0400 (EDT)
> From: [EMAIL PROTECTED] (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!)
>From the Unix98 standard:-
The number of bytes available for the new process' combined
argument and environment lists is {ARG_MAX}. It is
implementation-dependent whether null terminators, pointers,
and/or any alignment bytes are included in this total.
--
James Youngman
Manchester, UK. +44 161 226 7339
PGP (GPG) key ID for <[EMAIL PROTECTED]> is 64A95EE5 (F1B83152).
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
