[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:
http://lists.gnu.org/archive/html/libtool/2005-07/msg00115.html
> 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.
Cheers,
Ralf
- Re: Feature request: setting env vars for binary wrappers, Ralf Wildenhues, 2006/06/13
- Re: Feature request: setting env vars for binary wrappers, Gary V. Vaughan, 2006/06/14
- Re: Feature request: setting env vars for binary wrappers, Ralf Wildenhues, 2006/06/14
- Re: Feature request: setting env vars for binary wrappers, Gary V. Vaughan, 2006/06/15
- Re: Feature request: setting env vars for binary wrappers, Ralf Wildenhues, 2006/06/15
- Re: Feature request: setting env vars for binary wrappers, Gary V. Vaughan, 2006/06/15
- Re: Feature request: setting env vars for binary wrappers, Ralf Wildenhues, 2006/06/15
- Re: Feature request: setting env vars for binary wrappers, Gary V. Vaughan, 2006/06/15
- Re: Feature request: setting env vars for binary wrappers,
Ralf Wildenhues <=