Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm referring to *nix command line applications primarily, where you want to permanently modify the behavior from defaults.

Environmental variables are easily understood and implemented, usually requiring the user to modify their ~/.bashrc for a permanent change. However, namespace collision might be a problem (but unlikely if you're careful).

On the other hand, a lot of programs use ~/.programrc config files.

Is it simply verbosity? If your program only has 2 configuration settings, then a simple export APP_SETTING=1 works just fine. However if you're starting to offer 5+ options then it should be time to start looking into a config file?

share|improve this question

2 Answers 2

up vote 5 down vote accepted

There are many other pressures:

  • Writing a config file requires write permission on the file system (in fact, it requires a file system in the first place!). Environment variables can be set even if you are running a rescue system from a CD.

  • Environment variables can be set quickly and temporarily just for one invocation, which is much better for use in small shell scripts. (Rewriting and re-rewriting a config file risks destroying the original settings if the process doesn't terminate correctly. Temporary values die automatically.)

  • A config file can be passed around easily to some other user or pre-installed with a distribution. Telling someone how to use environment variables is much harder. You wouldn't believe how much harder it is to get normal people to type CDG_VERBOSITY=5 cdg correctly then just cdg.

  • Environment variables may or may not get inherited properly if your program farms out work to other processes. A config file is always there.

  • There can be surprisingly low limits on the size of the environment that can be passed to a process on some systems. The file system is much, much more forgiving.

  • If you need to change settings after program start, telling a process to re-read its config file is a well-known idiom. Changing the environment of a running process can be trickier.

  • Reading a config file hits the disk, which is massively slower than reading from the environment. A config file would be grossly inappropriate for something like grep, which is usually invoked on data that are entirely in memory.

share|improve this answer
    
To the above list, I would add: Config files can be stored under revision control, so a record can be kept of deployed configuration & configuration changes. –  William Payne Jun 12 '12 at 17:21

Config files (for the sake of keeping a record of configuration changes), overridden by (optional) environment variables (for the sake of temporary modifications in uncontrolled environments).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.