Re: Consensus: Tuning runtime behaviour with environment variables.

[Stephan Bergmann <sbergman at redhat dot com>]

On 05/29/2013 05:41 PM, Carlos O'Donell wrote:
> On 05/29/2013 03:09 AM, Stephan Bergmann wrote:
> > On 05/29/2013 06:56 AM, Carlos O'Donell wrote:
> > > - User changeable environment variables that impact library runtime
> > >     behaviour is dangerous.
> > >
> > >     * Could you specifically point out what you find dangerous?
> > >       I see no more danger than we already face when adding a new
> > >       API or reviewing code changes. How is this different
> > >       than all of the other work we do?
> >
> > One general problem of env vars is that they can all too easily
> > affect processes they were not intended to affect (like when the
> > target process spawns another process).
>
> Stephan,
>
> For the record, are you for or against using environment variables
> to tune library behaviour?
>
> You have made it clear that you are worried that the average user
> might not understand the implications of environment variables.
> Resolving that is going to be a process of education, but it is
> a downside to this feature. The user needs to be sufficiently
> educated about environment variables to understand they are
> passed on to child processes. My opinion is that users already
> understand this and that it is a feature, and that an API will
> help them reset all defaults if required before spawning. They
> can do that today by clearing GLIBC_* env vars along with the
> full list of LD_* and MALLOC_* env vars, but we will provide
> some convenience functions for this.

I wasn't thinking so much about clueless end-users in front of the 
shell, but rather about programmatic uses of env vars.  From my past 
experience (developing LibreOffice), LD_LIBRARY_PATH is probably a good 
example:

For one example, some test code run during the build needing 
LD_LIBRARY_PATH to find libs at "wrong" locations (in the build output 
tree rather than the product's install location), but spawning as 
subject-under-test an installed product that should /not/ be fooled into 
picking up the wrong libs, so having to tunnel the original 
LD_LIBRARY_PATH setting through the test code so that it can reset it 
accordingly when spawning the subject-under-test (using differently 
named env vars on different platforms, of course).

For another example, Sun's java traditionally re-spawning itself after 
modifying LD_LIBRARY_PATH so it finds its own libs in its various jre 
sub-dirs, but then forgetting to reset LD_LIBRARY_PATH when spawning 
another process via java.lang.Runtime.exec (so that if that process is 
LibreOffice, which happens to instantiate in-process a JVM from another 
JRE installation on the machine, things start to go bad).

(The example of LD_LIBRARY_PATH also indicates that what is required is 
not always functionality to clear the env, but sometimes it is 
functionality to reset an env back to a state before it got overridden.)

It's fun like that which prompts me to point out that general problem 
with env vars.  But for your specific question, I fear I need to chicken 
out.  I see both the pros and the cons, and I'm not sure what an ideal 
solution would look like,

Stephan