Translations: English - Italiano - Português (Brasil) - Русский
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 commands.
- HOME = Current user's home directory.
- LOGNAME = Current user's name.
- SHELL = The user's preferred shell.
- EDITOR = The user's preferred text editor.
- MAIL = The user's electronic mail inbox location.
To see your currently defined variables, open up your terminal and type the env command.
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. 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.
If you want to append something to a variable, instead of overwriting the previous value, 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:
- 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.
- 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
Text console logins end up with a login shell. Variables are acquired in stages, by multiple processes in sequence. Each process adds some more variables.
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.
init runs the start-up scripts from /lib/systemd/system (under systemd) or /etc/rc?.d based on the run level set in /etc/inittab (under sysvinit). Each service or script defines its own required environment variables. Under systemd, variables defined in various environment.d directories will be made available to systemd user units; see the environment.d(5) manual page for details.
At the end of booting, init runs a getty process on one or more virtual consoles. getty waits for the user to type their name, after which it sets the TERM variable and executes login to prompt for a password.
login checks /etc/passwd and /etc/shadow for the user's account details. If the password is acceptable, login sets HOME, SHELL, PATH, LOGNAME and MAIL based on the contents of /etc/passwd, checks PAM, and finally runs the user's login shell.
PAM may instruct login to read the variables in /etc/environment also. This is the default.
- The login shell starts and reads its shell-specific configuration files.
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. See DotFiles for full details.
- (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 display manager
The login process is quite different under a DisplayManager.
At the end of booting, the mother of all processes -- init -- is started.
init runs services as described above. One of these services will be your display manager.
When the user successfully logs in, the display manager checks PAM, and then starts an Xsession.
PAM may instruct the DM to read the variables from /etc/environment.
The Xsession reads ~/.xsessionrc and possibly other files depending on the session type.
Graphical logins do not read a shell's startup files (/etc/profile and ~/.profile and so on) by default, but you as a user may choose to create a ~/.xsessionrc file which does this.
For the hasty who just need to get the system running, here is what you can do:
Put all global environment variables, i.e. ones affecting all users, into /etc/environment
Remember, this file is read by PAM, not by a shell. You cannot use shell expansions here. E.g. MAIL=$HOME/Maildir/ will not work!
There is no shell-agnostic and login-independent solution to the problem of how to configure the environment for all users, beyond the trivial cases that PAM can handle.
Put all your transient shell settings (aliases, functions, shell options) in ~/.bashrc
Put all your environment variables in ~/.profile
Create or edit file ~/.bash_profile and include commands:
if [ -f ~/.profile ]; then . ~/.profile fi
Create or edit file ~/.xsessionrc and include the same commands as above.
This is a quicky and dirty approach! Not for the pedantic user.
Notes and exceptions
startx from terminal
If you start X Window (the GUI) from a text console, your environment variables are already defined by your login shell, 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.
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.
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. In Stretch and earlier releases, the su command resets your PATH environment value to one defined in /etc/login.defs by ENV_PATH and ENV_SUPATH variables. In Buster, su does not change your PATH variable (for details, see /usr/share/doc/util-linux/NEWS.Debian.gz).
Please note that using Gnome helper gksu from Gnome panel by default uses su internally (i.e. you may "lose" your PATH if you do not configure it in login.defs in stretch).
Does this mean gksu simply fails outright in buster due to the missing /sbin et al. in PATH?