[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
From: |
Lenny Foner |
Subject: |
CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20 |
Date: |
Mon, 23 Oct 2000 01:11:12 -0400 (EDT) |
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 <address@hidden>
Lenny Foner <address@hidden> 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
- CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, Lenny Foner, 2000/10/20
- Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, James Youngman, 2000/10/22
- CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20,
Lenny Foner <=
- CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, Lenny Foner, 2000/10/25
- Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, Larry Jones, 2000/10/25
- CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, Lenny Foner, 2000/10/26
- Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, Larry Jones, 2000/10/26
- Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, Frederic Brehm, 2000/10/26
- Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20, Larry Jones, 2000/10/26