[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: |
Tue, 13 Jun 2006 23:00:39 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]
Hi Behdad, everyone,
Sorry for the delay again.
* Behdad Esfahbod wrote on Thu, Mar 09, 2006 at 04:59:38PM CET:
> On Wed, 1 Mar 2006, Ralf Wildenhues wrote:
> > * Behdad Esfahbod wrote on Wed, Mar 01, 2006 at 05:15:17AM CET:
> > >
> > > This is a feature request for libtool. Let me describe the
> > > problem as I face it, so you may have a workaround for it
> > > already: I'm using libtool in the Pango text rendering engine.
> > > The Pango library accesses a file in $prefix/etc/pango/pangorc to
> > > find its modules at run-time. Now all I want to do is to be able
> > > to run the examples in pango/example when Pango is not installed.
> > >
> > > The easiest way that can be done is to set the PANGO_RC_PATH
> > > envvar to a special pangorc file. Another is to pass the
> > > --pangorc path-to-pango-rc to the examples if they understand it.
> > > What I need from libtool is to let me do one of these things in
> > > the wrapper it creates for uninstalled binaries.
[ my concerns were: we don't always build a wrapper ATM. ]
> > If we can find an answer to this question to define coherent semantics,
> > I'm all for it.
> Ok, this is my view of the problem: Running uninstalled programs
> requires some modifications to the environment. One is to make
> sure that the uninstalled libraries are linked. Other changes
> may be needed, on a per application basis. Libtool is free to
> choose how to implement these. So far it has only supported the
> library path modification, and implemented that using a wrapper
> script on some platforms, or using rpath on others (right?)
More or less, yes.
> The same goes with the other modifications. They can be easily
> implemented using a wrapper. So if there are such modifications
> requested, a wrapper should be used.
Yep. And that's really the easiest solution: as soon as extra arguments
or extra environment variables are passed, we always build a wrapper.
> My current workaround has been making pango-view accept a
> --pangorc path-to-pangorc parameter and defaulting to ./pangorc.
> But that opens up a known security problem... So I really want
> to "fix" it the right way.
I don't quite understand how this fixes any security problems...
but here you go with a suggestion (against current CVS HEAD).
The attached patch implements two new link flags, -wrapper-arg and
-wrapper-env, to prepend arguments to programs, and modify their
environment. They will force creating a (shell) wrapper.
Here's the hairy part about it: somebody may eventually want to extend
the C wrapper that is currently used on w32 to encompass all the
functionality that the shell wrapper currently has. And while I don't
have current plans about this, I still don't want to add any
unnecessary obstackles to it.
So whatever we add to the shell wrapper should be doable easily in a C
wrapper as well. This led me to add these restrictions: the
-wrapper-env works like putenv: you pass an argument `var=value', the
variable will be exported, the value will _not_ be interpreted by the
shell any more. For now you cannot unset variables (this is to cater
for hosts with a shell that does not support `unset'), and, e.g.,
-wrapper-env 'foo=$bar'
will cause the environment variable `foo' to contain the four characters
$, b, a, and r, not the contents of the variable $bar.
Similarly, -wrapper-arg will add exactly one literal argument to the
exec. I've put suitable quoting in place for this to work with most
kinds of input, and of course a test to this end.
What do you think? OK for HEAD right now, or do you think this is too
intrusive now?
I think we should not backport this to 1.5.x, it is a new feature.
Cheers,
Ralf
env-wrapper3.diff
Description: Text document
- Re: Feature request: setting env vars for binary wrappers,
Ralf Wildenhues <=
- 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, 2006/06/15