[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shell wrapper bug exists in 1.4.3, too
From: |
Bruce Korb |
Subject: |
Re: shell wrapper bug exists in 1.4.3, too |
Date: |
Fri, 14 Feb 2003 13:51:04 -0800 |
Kevin Ryde wrote:
>
> Bruce Korb <address@hidden> 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.