[nSLUG] abuse of environment variables

George N. White III gnwiii at gmail.com
Sun Sep 21 11:54:04 ADT 2008

I've spent way too much time tracking down places where environment
variables have been
set to values that cause something to break:

Example 1:  TeX

Some MiKTeX (probably the most widely use TeX distribution) users have
which causes LaTeX to load macros from the .macros subdirectory of the
current directory.
Then they decide to try TeX Live, and TeX Live fails because it uses
TEXINPUTS internally:

Z:\home\gwhite>kpsewhich -var-value TEXINPUTS

So, MiKTeX interprets TEXINPUTS as adding a directory to an existing list of
search paths, while TeX Live expects it to provide not just the complete list
of paths, but also indicate whether to use an ls-R database (!!) and whether
to search subdirectories (//).

Efforts are underway to port MiKTeX to linux (the package manager has been
available for several years), so this issue may affect linux in the future.

An experienced user needed to use LaTeX macros from a major publisher to
typeset a book.  He found instructions on the web that told him to set
TEXMF=<something>.  Months pass and he decided to update TeX Live, but
can't get it to work, even after a reinstall.  All the installation
and setup works
fine because his environment setting was not used, but he was not able to
format documents because the TEXMF setting conficts with those needed
for his new install.

Example 2: flexlm is evil

At work we have a mix of node-locked and floating licenses.  One of the systems
with a node locked license is failing, and some floating licenses were
needed for
a pilot project, so a) the fixed license was moved to a machine that
had previously
relied on floating licenses.  Users were asked to change to the new
licenses, but
in practice that is beyond the capacity of many users:

0.  "root" does noit get involved in managing the licenses, so they aren't
     just set "system wide"
1.   license variables can be read from $HOME/.flexlmrc
2.   license variables can be set in shell startup scripts or by applications
3.   for Apple MacOSX, licenase variables can be set in

To make things worse, the environment changes between regular user
logins, cron scripts, ssh sessions, and su <other user>.

Example 3: Red Hat network interfaces

Who would guess that to have ethtool change the settings when
the interface is started, you need to set ETHTOOL="<args>" in

I suppose somewhere there is an "Environment Varaibles
Considered Harmful" paper, and also a chapter in the Debian
manuals on how not to use environment variables.


The main problems:

0. there is nothing to prevent different applications or different
    versions from assigning different meanings to the same variable.

1. there are way too many ways to set variables.  Some shells
   do have a "readonly" attribute, so it may be possible to
   block changes by random scripts

2.  a variable that is used exactly once may be set in some
    distant configuration file.   This seems like abuse of a
    mechanism meant for global sharing across apps.

George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

More information about the nSLUG mailing list