---

General

Environment variables are named strings available to all applications. Variables are used to adapt each application's behavior to the environment it is running in. You might define paths for files, language options, and so on. You can see each application's manual to see what variables are used by that application.

That said, there are several standard variables in Linux environments:

• PATH = Colon separated list of directories to search for binaries.
• HOME = Current user's home directory.
• USER = Current logged in user's name.
• SHELL = The current shell.
• PS1 = Defines shell's command prompt.
• EDITOR = defines the user's preferred text editor.
• (please feel free to add more)

To see your currently defined variables, open up your terminal and type the command env

Variables are defined with name-value pairs: "NAME = any string as value". The variable name is usually in capital letters. Anything that follows the equal-sign is considered the variable's value until the terminating line feed character. Any whitespace around the equal-sign is ignored. Variables can be defined ad hoc in a terminal by writing the appropriate command. In Bash this would be 'export MYVAL=Hello world'. In this case the variable stays defined until the end of the terminal session.

When working in shells or shell scripts: If you do not want to over-write the previous value of the variable, include the variable name into the new definition. E.g. in Bash: export PATH=$PATH:~/bin. This example shows how to append the bin directory in the user's home directory onto the PATH environment variable.

In most cases it is most convenient to store these variables in a configuration file that is read during system boot and user login so that they are available automatically. Unfortunately this not always as easy as it sounds. Why? For a couple of reasons:

1. Environment variables are inherited; i.e., the parent program sets the environment for the child process. You need to configure the parent's settings so that it passes it on for all its children.
2. Various shells and window managers are the parent programs we are looking for but each of them reads a different configuration file (dot file) when it starts.

So, with this knowledge we understand that we need to consider both the starting order of system processes and the configuration files they read when they are started. See the DotFiles page, or read on ...

Lets get to it! There are two ways you can run your Linux box: from text console or graphical user interface.

Using text console

Boot process in regards to environment variable definition when a text console (also called login shell) is used.

1. At the end of boot the mother of all processes init is started. init's environment, including PATH, is defined in its source code and cannot be changed at run time.

2. init runs the start-up scripts from /etc/init.d depending on the run level set in /etc/inittab. Since init's environment is very bare, the scripts define their required environment variables within themselves.

3. init starts the text login process that waits for the user to log in. When the user logs in, the login process checks /etc/passwd to see what shell should be started for this particular user.

4. The shell starts and reads its shell-specific configuration files. 

   1. Bash first reads /etc/profile to get values that are defined for all users. After reading that file, it looks for ~/.bash_profile', ~/.bash_login', and `~/.profile', in that order, and reads and executes commands from the first of these files that exists and is readable. b. (please fill in other shells as well)

Now the environment variables are ready to be used by the applications you start from the terminal.

Using graphical UI

Boot process in regards of environment variable definition when graphical login is used. (Information here is Gnome / GDM specific)

1. At the end of booting, the mother of all processes -- init -- is started.

2. init runs the start-up scripts from /etc/init.d depending on the run level set in /etc/inittab. Since init's environment is very bare, the scripts define required environment variables within themselves.

3. Init starts the GDM display manager, which in turn will start the graphical login.

4. When the user successfully logs in, GDM starts xsession, which reads the file /etc/gdm/Xsession and with it the environment variables for the user's session. The default version of the Xsession file first reads /etc/profile for global settings and then ~/.profile to add the user's individual settings.

Now the environment variables are set and used when programs are run in this session.

Quick guide

For the hasty who just need to get the system running, here is what you can do:

• Put all global definitions, i.e. ones affecting all users into /etc/profile.

• Insert all personal definitions into ~/.profile

• Create or edit file ~/.bash_profile and include commands:

   if [ -f ~/.profile ]; then
  
       . ~/.profile
  
   fi

Notes and exceptions

startx from terminal

If you start X Window (the GUI) from a text console, your environment variables are already defined as explained above. However, the window manager may read the same files again (see below). This is usually not a problem, but you may get unexpected results, such as PATH having all entries listed twice.

Shell cascading

If you start another shell within the login shell (yes it is possible), the second one is a non-login shell. It will not read named start-up files but searches non-login start-up script from user's home directory instead. With Bash it is called ~/.bashrc. To avoid specifying same values in two places usually the login-shell start-up script ~/.bash_profile includes the ~/.bashrc at the end of its execution. To implement include following into your ~/.bash_profile:

if [ -f ~/.bashrc ]; then

   . ~/.bashrc;

fi

terminal windows in X

If you start terminal / console window in graphical desktop environment it will be non-login terminal and it will read only the user's non-login start-up script. For Bash this is ~/.bashrc.

Using su

The su command is used to become another user during a login session. It is commonly used to get root permissions temporarily from normal session. su command resets your PATH environment value to one defined in /etc/login.defs by ENV_PATH and ENV_SUPATH variables. Please note that using Gnome helper gksu from Gnome panel by default uses su internally (i.e. you will "lose" your PATH if you do not configure it in login.defs).