On the Use of Environment Variables? 20
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?
Best of both worlds (Score:3)
Environment and Configfiles (Score:5)
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. :-)
lazy programming? (Score:3)
Now having said that, the question is whether the computer this runs on will be a "dedicated" workstation to THIS application... if so, you could get away with a ton of E.V.'s. If not, I'd hate to see the system cluttered up with unnecessary E.V.'s the rest of the time.
On Windows, I prefer Registry Entries over config files, but that's a personal preference.
MadCow.
My experience with configuration values (Score:4)
Every configuration option must have a sane (and documented) default. Period.
A configuration file has the following advantages:
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.
Env. variables least of your worries (Score:3)
Uh... forgive me for sounding crass, but if that's the case, you probably have bigger battles to fight than env. variables vs. config files.
Ryan T. Sammartino
This is one of my pet peeves (Score:3)
1) A config file can be edited with vi. Environment variables are usually tinkered with at the command line. vi is a better place to do a lot of typing, especially if you're using the Bourne shell.
2)Environment variables are listed with the set command, which dumps them in a particular order, namely alphabetical. Now, lots of config vars are heiarchal in nature, with things like the global dir set first, then some subdirs depending on the global dir variable, and then maybe specific program configs at the lowest level, depending on directory. A config file lets you organize this in a better way, and use format to give the user some clues.
3) All my bad memories of trying to install some massive 5 gigabyte program across several servers with hundreds of files and directories come down to one thing: I had to check every single environment variable by hand and make sure that it was correct. Who feels like finding the mistake in something like PROGRAMDIR=/opts/one/two/three/four/five/zix/seve
4) lastly, config files can have COMMENTS in them. In fact, you can build your configuration file so that no external documentation is required. Look at the file, read the comments, and make the program work.
It depends on the environment. (Score:2)
This is far easier than having to write a program which parses someone else's config file, returning an error code, and then branching the batch based on the error code returned, or, even worse, storing the required info in both a variable and config file.
Ideally you'll give the user a choice, as suggested above, by allowing usage of environment variables, config file, command line, default config file, and program defaults.
But it sounds to me as though 1) you haven't asked the guy WHY he wants to stick with environment variables or 2) he doesn't have a good answer. Backwards compatability is a good answer, though, and it's not to hard to maintain backwards compatability and put a config file and command line options in there as well.
-Adam
This sig 80% recycled bits, 20% post user.
Re:This is one of my pet peeves (Score:2)
DON'T make an environment variable that contains the path to the configuration file.
Put the damn config file into
Thank you very much for the opportunity to rant.
sensible policies (Score:4)
Here is the policy that I try to follow in my programs:
- Default Values: Provide reasonable default values, hard coded into the program, in case the program is run without any configuration.
- Config Files: Search for a configuration file in a number of reasonable locations and override any default values with values from the configuration file.
- Envronment Variables: Override default values or values from the config file with anything found in the environment.
- 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.
Re:Env. variables least of your worries (Score:1)
Just a case of a lazy programmer not checking the results of getenv(). That shouldn't be too hard to fix.
Logout/Reboot? (Score:2)
A (badly-done) config file. ;)
Some advice: use both! (Score:2)
One popular combination is to use an environment variable to point the program suite to a configuration file or directory of configuration files.
Re:This is one of my pet peeves (Score:3)
DON'T make an environment variable that contains the path to the configuration file. /usr/local/etc where it belongs, and have your program look there and only there.
Put the damn config file into
Bah. I put most of my personal installs into /opt/ so /usr/local/etc does nothing for me. Yeah I could symlink but that's a pain; why not allow $CONFIG_PATH and default to /usr/local/etc?
Your post comes along as so much old-timerism that I can smell the Ben Gay from here.
My pet peeves are people who talk before thinking (Score:2)
Environment varioables are also edited with VI, in your .profile, .login, or .cshrc file. Unless you're testing, you never log in and have to type things like "export HOME=/home/tbone".
Environment variable are dumped in whatever order they were pushed into the environment stack. Unless the shell reorders your environment for you, most shells do not alphabetize your vars. Besides, if you're going to use the environment to store variables in, you should be using a syntax like PREFIX_VARIABLE=value. Then you can 'set | grep PREFIX' | mail -s "Environment problems" suport@company.com" and get an answer back.
You mean you had to edit your PATH variables? God forbid you actually do sysadmin work and set up your paths for your software....
Comments are for weenies :)
In all seriousness, Env variables should be part of a larger scope of things. Parsing configurables should work like this:It's not exactly efficient (4 config passes), but it's not like you're reading the Windows Registry 4 times or anything.
This space for rent. Call 1-800-STEAK4U
Middle ground? (Score:1)
This was a utility that I chose to implement as a couple of bash scripts. It stored and retrived the state of the system in a config file consisting of environment variable assignments, which it could in turn source back in. The big unforseen benefit was that the system could change its state by making edits to the file, then sourcing it in again, and it would automagically inherit the self-consistent edited new state. (So long as the edits were logically correct, at any rate; but I didn't have to make parallel edits to the config and to the runtime state.)
I admit again, this doesn't map strongly to the exact literal question at hand. The parts of this design that did are:
Hope someone finds this useful.
--
My rule of thumb (Score:4)
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.
Re:This is one of my pet peeves (Score:1)
Don't you mean "put the system default config file in /etc/<pgmname>/default.conf and the user-definable overrides in $HOME/.<pgmname>.conf?
Re:This is one of my pet peeves (Score:2)
Damn. I'm 32 years old, but thank you for the compliment.
"And we LIKED it too!"
Another suggestion... (Score:3)
Use a config file, of course - but use XML as the format for that config file.
The main reason is for human readability, as long as you make your node names, etc - sufficiently readable. Furthermore, you could include nodes that would allow for user defined settings (if that is the reason that environment variables were being used) - these nodes could specify where to look for the user's XML config file (say, in $HOME/appname/userconfig.xml) - which the user could edit easily - if the config file is absent (or the path doesn't exist, etc) - the parser could supply default values (perhaps picked out from the main config file - which the user couldn't edit).
Using XML might make things more difficult (especially if you have to write your own parser) - but if you are writing from the ground up anyhow, you might as well set up to use XML, because your app will probably need it (intercommunication between different app sections - especially if you are black boxing everything to make parts very reusable. Also if you are using an XML format that is well defined, you can easily create back ends for any data sharing for third party apps that might be needed).
Worldcom [worldcom.com] - Generation Duh!
Re:Best of both worlds (Score:2)