Process environment

On Unix-like operating systems, one way a process can take input its through its "environment", which is a set of variables automatically inherited from the process that started it (its "parent process"). For example, when you start a program from your shell, it inherits your shell's environment. So, what kind of variables are in your shell's environment?

One of them is HOME, which is set to the absolute path to your home folder. (They are usually named in all caps.) You can see it by running `echo $HOME`. If you haven't seen it already, `echo` is a shell command that just prints whatever text you give it to stdout, and the $ symbol tells your shell that `HOME` is not literal text but the name of an environment variable. So, any program you start from the shell can find out what your home folder is by reading this variable from its environment.

Another one is PATH, which is a list of folder paths, separated by colons, that commands are installed in. When you type a command like `ls`, your shell looks at the PATH variable in its environment, and tries to find the `ls` binary inside one of those folders. Try `echo $PATH`. You'll probably see something like `/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin`. Also, feel free to `ls` any of those folders to see which commands they contain.

Your environment probably has a bunch of other, relatively obscure things in it. You can see all of them with the command `env`.

Now, compare four different ways a process can take input: arguments, environment, stdin, and configuration files. Consider what each is best used for.

arguments:

Specified explicitly by the user each time the program is run
Structured as an ordered list of things
Pre-loaded into memory when the process starts

environment:

Specified implicitly
Structured as a set of named values
Pre-loaded into memory when the process starts

stdin:

Specified explicitly
Structured as a formless stream
Requires syscalls to read

configuration files:

Specified implicitly
Structured as a formless stream
Requires syscalls to read
Ties the program to a file other than its executable
Can be used for persistent changes from within the program. For example, a graphical program can provide a settings menu that saves your changes in a configuration file.