[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request: setting env vars for binary wrappers

From: Ralf Wildenhues
Subject: Re: Feature request: setting env vars for binary wrappers
Date: Thu, 15 Jun 2006 14:25:51 +0200
User-agent: Mutt/1.5.11+cvs20060403

* Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 02:00:28PM CEST:
> Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Thu, Jun 15, 2006 at 12:57:42PM CEST:
> >> Ralf Wildenhues wrote:
> >>       ${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).
> Good point.  However, the intent of this wrapper was to centralize
> and simplify the code in the autotest suite to work equally with
> installed and uninstalled m4, so timeliness of stderr isn't an issue.

Given that just yesterday I started a debug session of CVS m4, let me
assure you this *is* an issue.  Besides the fact that
  libtool --mode=execute gdb ...

-- even if it's not nice -- works for the libtool wrapper but not for
the hand-written one, and is another precedent for centralizing issues
in one wrapper.  (FWIW, I'm not yet done with the session...)

> I don't suppose many people will go to the effort of breaking in to
> my machine just to overwrite a few files in my home directory.

I regularly debug on systems I do not own nor know all users of.

> >>   status=$?
> > 
> > Using the variable status is not portable, as is using ${1+"$@"} without
> > taking care of zsh.
> I wasn't aware of the former,  I need to read up more on zsh.  Thanks.

Both issues are listed in the Autoconf portability section.

> > 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.
> I'm still somewhat ambivalent.   My only reservation (and it isn't
> a strong one admittedly) is that there will always be cases where
> libtool doesn't (yet) cover various useful things one might like
> to do in a shell wrapper... and this simple m4 wrapper alone has
> shown us a few more we haven't tackled yet.  Surely there will be
> many others...

The mentioned ones (argv[0] contents, uninstalled file paths) are by far
the most reported ones, and the only ones I am aware of.  Bruno once
posted a nice summary + workarounds:

> Perhaps putting the common ones into libtool, but also documenting
> the wrapper script technique for users who want to do uncommon things
> that lend themselves to this approach?

I think the wrapper script technique is well known.  All bug reports to
this end revolve around improving upon that state of things.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]