On the Use of Environment Variables?

ender-iii asks: "The company I work for is ready for a ground up revamp of our application. The old version relies heavily on environment variables (so much so, that if they aren't set, the app core dumps!). The old programmer wants to do the same thing and put all configuration in the environment. I am arguing for a config file. My question is this: why would anyone use environment variables for a standalone application?" I can think of lots of reasons where an environment variable for certain settings is better than having to edit a configuration file (user overrides of that setting, for example...and many time users aren't going to have write perms to config files!) however, they have the strongest value when used appropriately. If you are setting 10-20 variables in the environment, then you really should be thinking about a config file of some sort...not every admin/user will be happy cluttering their environment with unnecessary variables. What do you all consider appropriate use of ENV variables, and when is it acceptable to use it to store lots of config information?

Comments

Environment and Configfiles

[winterstorm]

The utility of environment variables is indicated by the name. The environment that a program runs in should have influence on its behavhior. For instance the program should decide how many columns of text to display from a config file... what if the screen has 80 columns by the config file says 40? Environment variables should describe to a program what environment it is running in. Environment variables should answer quesitons like, "what is the name of the user running me?", "what is my current working directory?", "where should I find my config file?", "what kind of terminal am I running on? do I HAVE a terminal?".

I think that there is nothing wrong with the same data being represented in a config file and the environment. In fact the best way is to have a global config file in /etc, a user specific config file (.somethingrc), and allow environment variables to override the config files. I disagree with the idea of replacing all your environment variables with a single once that just has the location of a config file. If your environment variables do indeed describe the working environment for the program then they should be in the environment.

This isn't a slight or insult or sarcasm at all; you would probably find a book on the history of unix to be of benefit. You've obviously got the wisdom to ask, "why do we need these variables" when so many others just use them for EVERYTHING or use them for NOTHING. You'll get more insight from a book drawing your own conclusions than from us here.

Oh, and if your program core dumps when a variable isn't set... that's just bad coding and you should be as suspicious as your are. :-)

My experience with configuration values

[Lumpish Scholar]

... based on over three years with the (commercial, non-open, non-free, cross platform) product I've been working on (and ported from NT to Solaris), and twenty years in the industry. The following advice applies to both Unix and other, less worthy, operating systems.

Every configuration option must have a sane (and documented) default. Period.

A configuration file has the following advantages:

• If the user has a problem, he or she can send you the configuration file. This is easier than sending you an environment dump.
  
• Users can more easily back up a configuraion file than all the combinations of things that set environment variables. (Eudora keeps everything it needs in one directory structure. Trivial to back up. Trivial to support multiple users on the same machine. Very nice.)
  
• If your product can read the configuration file, perhaps your product can write the configuration file, too. Look at Sun's OpenLook mail tool, or at Z-Mail: both use (effectively) the .mailrc format, but provide (purely optional) GUI interfaces to set most or all of the options. Speaking as a one-time mailx guru, I found this much more convenient than surfing mailrc(1) options list (which I was, thank you very much, quite capable of doing).

Environment variables have the advantage of really simple ad hoc experimentation:

$ MAGICFOO=bar yap # or
% env MAGICFOO=bar yap

We use one environment variable, which points to the directory where our configuration file lives.

Don't talk to me about "the registry". Our product doesn't use the registry. Eudora doesn't use the registry. Both greatly benefit as a result of this non-use. The registry is a black hole: everything falls into it, because it really sucks.

sensible policies

[dutky]

Here is the policy that I try to follow in my programs:

1. Default Values: Provide reasonable default values, hard coded into the program, in case the program is run without any configuration.
2. Config Files: Search for a configuration file in a number of reasonable locations and override any default values with values from the configuration file.
3. Envronment Variables: Override default values or values from the config file with anything found in the environment.
4. Command Line Parameters: Override everything else with anything specified explicitly on the command line.

As an added bonus, I try to provide a command line flag that will cause the program to dump the current configuration to a file, along with as much documentation (your configuration file format should allow for comments so it can be documented in situ) as is needed to understand and edit the file.

Only in extreme circumstances should the program come to a point where it cannot proceed because of missing configuration information. If it does come to such a point, it certainly shouldn't core dump. Rather, it should display an informative error message, indicating which configuration parameters are missing and giving some advice on how to either obtain a basic configuration file or set the required paramter.

My rule of thumb

[coyote-san]

My rule of thumb on this is simple - if it only affects one program (or a related suite of programs), it should go into a config file.

Environment variables should only be used for things that are interesting to multiple, unrelated applications. Things like PAGER, EDITOR or VISUAL.

If you want to have the ability to override the values compiled into the executable or in the config file, use "-Dname=value" and "-Uname" on the command line. Only check the environment variables for this if there's a compelling reason to do so. (E.g., "CFLAGS" has been supported for so long that no C compiler or preprocessor can reasonably ignore it.)

Config files aren't quite as convenient as environment variables for some types of coding, but the flip side is that you don't have to worry about name collisions in the environment variable namespace, platforms that impose limits on the number of environment variables, etc.