[nSLUG] abuse of environment variables

Daniel Morrison draker at gmail.com
Sun Sep 21 14:24:38 ADT 2008

2008/9/21 George N. White III <gnwiii at gmail.com>:
> I've spent way too much time tracking down places where environment
> variables have been set to values that cause something to break:

I agree with all that.  It's a real hassle.

> http://wuetender-junger-mann.de/wordpress/?p=462

Unfortunately, this is advice for application programmers, and doesn't
help poor sysadmins when all sorts of applications that are required use
environment variables heavily.

My attempts to mitigate this problem revolve around the idea of setting
the environment variables as needed for the applications, and NOT in the
shell in general.

Halfway there:

tell your users: before you use package XYZ, type:
   . /path/to/XYZ.sh
Then the environment variables are set only in the shell which is about to
execute the application in question.  However this still leaves the shell
running with variables set in it, like a time bomb (the user will lose
track of which shell is which).  It also requires the user to launch
applications from a cmd line!

All the way there:

Better is to create a wrapper script around the application executable.
This will set the environment variables for the application only.  Then
the wrapper script can be used in menu items or panel button launchers.
It always works properly because the env variables are set, and it doesn't
interfere with anything else.

If an application has three dozen cmd-line programs that all expect the
environment variable to be set (e.g. sun grid engine!) then you can a)
just live with the variables cluttering up the environment :(
(SGE_HOME=/usr/sungrid is probably pretty safe, if you only have one
version of SGE), or b) write a wrapper script that checks its $0 to find
out what was invoked, so as to execute the correct command, and then make
links so that the script is invoked for every cmd-line program name.

If users absolutely require unique env variable configurations, then
either they're capable enough to do it themselves, or, you'll need to
add custom options, by username/UID, to the wrapper script (this is where
making the all those links in the previous step is helpful -- only have to
customize for a particular user once in the master script!).

Hope this might be helpful,


PS: I'm enjoying this, but it seems maybe what we really need is a
"Nova Scotia Sysadmin Sympathy & Support Group" mailing list! (NSSSSG

More information about the nSLUG mailing list