Environment variables

Most Linux distributions tell you to change or add environment variable definitions in /etc/profile or other locations. Keep in mind that there are also package-specific configuration files containing variable settings such as . Be sure to maintain and manage the environment variables and pay attention to the numerous files that can contain environment variables. In principle, any shell script can be used for initializing environmental variables, but following traditional UNIX conventions, these statements should only be present in some particular files.

The following files can be used for defining global environment variables on your system, each with different limitations:

• is used by the pam_env module and is shell agnostic so scripting or glob expansion cannot be used. The file only accepts pairs.
• /etc/profile initializes variables for login shells only. It does, however, run scripts and can be used by all Bourne shell compatible shells.
• Shell specific configuration files - Global configuration files of your shell, initializes variables and runs scripts. For example Bash#Configuration files or Zsh#Startup/Shutdown files.

In this example, we add ~/bin directory to the for respective user. To do this, just put this in your preferred global environment variable configuration file (/etc/profile or ):

You do not always want to define an environment variable globally. For instance, you might want to add /home/my_user/bin to the variable but do not want all other users on your system to have that in their too. Local environment variables can be defined in many different files:

• User configuration files of your shell, for example Bash#Configuration files or Zsh#Startup/Shutdown files.
• systemd user environment variables are read from .

To add a directory to the for local usage, put following in :

export PATH="${PATH}:/home/my_user/bin"

To update the variable, re-login or source the file: .

If an environment variable only affects graphical applications, you may want to restrict the scope of it by only setting it within the graphical session.

To set environment variables only for a specific application instead of the whole session, edit the application's .desktop file. See Desktop entries#Modify environment variables for instructions.

Some graphical environments, (e.g. KDE Plasma) support executing shell scripts at login: they can be used to set environment variables. See KDE#Autostart for example.

The procedure for modifying the environment of the Xorg session depends on how it is started:

• Most display managers source xprofile.
• startx and SLiM execute xinitrc.
• XDM executes ; see XDM#Defining the session.

Though the end of the script depends on which file it is, and any advanced syntax depends on the shell used, the basic usage is universal:

~/.xprofile, ~/.xinitrc, or ~/.xsession

...
export ''GUI_VAR''=''value''
...

Since Wayland does not initiate any Xorg related files, GDM and KDE Plasma source systemd user environment variables instead.

No other display managers supporting Wayland sessions (e.g. SDDM) provide support for this yet.

Sometimes even stricter definitions are required. One might want to temporarily run executables from a specific directory created without having to type the absolute path to each one, or editing shell configuration files for the short time needed to run them.

In this case, you can define the variable in your current session, combined with the export command. As long as you do not log out, the variable will be using the temporary settings. To add a session-specific directory to , issue:

$ export PATH="${PATH}:/home/my_user/tmp/usr/bin"

The PAM module loads the variables to be set in the environment from the following files in order: , (and the deprecated ).

must consist of simple VARIABLE=value pairs on separate lines, for example: 

EDITOR=nano

and  share the following format: 

VARIABLE [DEFAULT=value] [OVERRIDE=value]

and   are special variables that expand to what is defined in . The following example illustrates how to expand the  environment variable into another variable: 

XDG_CONFIG_HOME   DEFAULT=@{HOME}/.config

The format also allows to expand already defined variables in the values of other variables using ${VARIABLE} , like this:

GOPATH DEFAULT=${XDG_DATA_HOME}/go

VARIABLE=value pairs are also allowed, but variable expansion is not supported in those pairs. See for more information.

• contains the path to the user's preferred shell. Note that this is not necessarily the shell that is currently running, although Bash sets this variable on startup.

• contains command to run the program used to list the contents of files, e.g., .

• EDITOR contains the command to run the lightweight program used for editing files, e.g., /usr/bin/nano. For example, you can write an interactive switch between gedit under X or nano, in this example:

export EDITOR="$(if [[ -n $DISPLAY ]]; then echo 'gedit'; else echo 'nano'; fi)"

• contains command to run the full-fledged editor that is used for more demanding tasks, such as editing mail (e.g., , vim, emacs etc).

• contains the path to the web browser. Helpful to set in an interactive shell configuration file so that it may be dynamically altered depending on the availability of a graphic environment, such as X:

if [ -n "$DISPLAY" ]; then
    export BROWSER=firefox
else 
    export BROWSER=links
fi