Re: shell wrapper bug exists in 1.4.3, too

Kevin Ryde wrote:
> 
> Bruce Korb <bkorb@xxxxxxxxxxx> writes:
> >
> > Next step is CVS, but meanwhile, this is the command line
> > in the failing shell script:
> >
> >   exec $program ${1+"$@"}
> 
> I'm not sure I understand the full circumstances, but perhaps it's the
> dodgy word splitting in zsh described in the autoconf manual "Shell
> Substitutions".
> 
> I encountered a problem with this construct on an ancient bash
> recently too, where ${1+"$@"} came out as an empty argument, rather
> than nothing (the same as "$@" is well-known to do).
> 
> Autoconf suggests testing $#,
> 
>           case $# in
>           0) something ;;
>           *) something "$@";;
>           esac

Thanks, Kevin.  I had guessed out most of this.  The problem remains
with libtool.  If libtool is going to generate a wrapper script around
an executable, then it must _ensure_ that it behaves with the proper
semantics.  In this case, it split a single argument into two because
there was white space in the argument.  It is with certainty a bug
in zsh.  (And antiquated bash-es I would guess, too.)  Here are the
possible fixes:

1.  libtool incorporates a program, "run.c" in the distribution.  That
    program gets compiled at configure time and is copied into place
    where, in the past, this shell script was installed.  This program
    would set up the required environment variables for the executable
    at hand and then would run exec(2) on the hidden executable.
    Presumably, if it were invoked as:

      some/path/foo

    it would read up the file:

      some/path/.lib/foo.rc

    set up environment variables and then exec:

      some/path/.lib/foo

2.  At configure time, libtool's configury magic would grope around the
    system for a shell that understands the exec $program ${1+"$@"}
    construct.  If it could not find such a beast, it can warn the user,
    set itself up to run zsh anyway and allow the rest of the configury
    script to test for the kind of shell chosen.  My tool will simply die.
    I don't think splitting quoted arguments is acceptable.

3.  Stop messing with dynamic links in the build directories.
    Use a static link with local libraries and reserve the dynamic
    linking for the install step.  After all, from the perspective
    of my tool, the correctness of both methods should be presumed.
    The only difference is the size of the executable.  This would
    actually make it much simpler to debug anyway.  It is quite the
    nuisance to type:

        gdb some/path/foo

    only to have gdb remind you that "foo" is a shell script and
    then you remember that you cannot type:

        gdb some/path/.lib/foo

    anyway because the environment variables won't be set and if
    they were set, the binary might be "lt-foo" anyways.  Ick.

I'm willing to write "run.c", but I'm hesitant to mix it up with a 150K
shell script.  I've been too busy of late.