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?

2 Answers 2


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.

  • 1
    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. Commented Jun 12, 2012 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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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