Re: Feature request: setting env vars for binary wrappers

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:57:42PM CEST:
> Ralf Wildenhues wrote:
> > 
> > So could you please list the technical problems you see with this patch,
> > so I can fix them, if any?
> 
> Starting to add new features on this side of the 2.0 release is like
> the road to hell (paved with good intentions, yet doesn't lead to
> somewhere we want to be).

Yes.  You already mentioned that, and I did not object.  But you
mentioned that *in addition to* some idiosyncracies, and I wanted to
know what they were.

> I don't strongly object to the patch.  However, CVS M4 achieves exactly
> this in a much more elegant fashion by simply including its own wrapper
> script to set the module load path for uninstalled m4 to load modules
> from the build tree.  It also sanitises the error output to make writing
> tests easier (something libtool wrapper scripts shouldn't do), and can
> be easily extended without adding complexity to the libtool code.

So you think having a wrapper for a wrapper is a better general solution
to the problem?  Well, if I can tell correctly, this is what Behdad and
Bob and everyone has been using so far.

>   #! /bin/sh
>   # @configure_input@
>   # Wrapper around a non installed m4 to make it work as an installed one.
> 
>   "@abs_top_builddir@/src/m4" \
>       --module-directory="@abs_top_builddir@/modules" \

This part is fine, and can be achieved by my patch.

>       ${1+"$@"} 2>/tmp/m4-$$

This is very very unfortunate for debugging.  I won't see the output
when it appears, which is sometimes crucial for a debug session.
Besides the fact that this line is a rampant security hazard
(I do `ln -s /tmp/m4-1234 /home/gary/some/important/file' for a few
probably PIDs, and you'll be sorry).

>   status=$?

Using the variable status is not portable, as is using ${1+"$@"} without
taking care of zsh.

>   sed 's,^[^:]*[lt-]*m4[.ex]*:,m4:,' /tmp/m4-$$ >&2

I intend to fix the changed naming in libtool eventually, if possible.
(Using an executable wrapper is one possibility that would work for many
systems; having the relinked binary with the same name, but in another
subdirectory helps, too; for bash, we could cheaply use "exec -a"; but
all this is work still to do...)

So all I see with this wrapper is a definite advantage for fixing things
*inside* the libtool wrapper, and not moving this work to third parties.

Cheers,
Ralf