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

[Lenny Foner]

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