Understanding Environmental Variables

Environmental variables control the configuration and functioning of the operating system shell. When you install either a Linux or Unix/Unix-like operating system such as FreeBSD or OpenIndiana, you’ll find that a default set of environmental variables has already been defined at both the global and user levels.

To see the list of environmental variables and their settings, use the env command, like so:

[donnie@fedora ~]$ env
SHELL=/bin/bash
IMSETTINGS_INTEGRATE_DESKTOP=yes
COLORTERM=truecolor
XDG_CONFIG_DIRS=/etc/xdg/lxsession:/etc/xdg
HISTCONTROL=ignoredups
. . .
. . .
MAIL=/var/spool/mail/donnie
OLDPWD=/etc/profile.d
_=/bin/env
[donnie@fedora ~]$

The complete list of environmental variables is very extensive. Fortunately, you don’t need to memorize what each and every item does for you. Most of the ones that you do need to know are self-explanatory.

Instead of viewing the entire list, you can also view the value of a specific item. Just use the echo command, and precede the variable name with a $, like so:

[donnie@fedora ~]$ echo $USER
donnie
[donnie@fedora ~]$ echo $PATH
/home/donnie/.local/bin:/home/donnie/bin:/home/donnie/.cargo/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin
[donnie@fedora ~]$ echo $EDITOR
/usr/bin/nano
[donnie@fedora ~]$

Here we see that I (donnie) am the current logged-in user, what my path setting is, and what my default editor is. You would view the value of any other environmental variable the same way.

An important thing to note is that the names of all environmental variables always consist of all upper-case letters. Nothing in either the operating system or the shell prevents the use of lower-case letters, but there is a very good reason for not using them. It’s just that variable names are case-sensitive. Best practice dictates using nothing but upper-case letters for environmental variable names and either all lower-case letters or a mix of upper and lower-case letters for programming variable names. This will prevent you from accidentally overwriting the value of an environmental variable. (I’ll show you more about that in the next section.)

As I mentioned before, environmental variables are configured at both the global and user levels. Variable settings at the global level affect all users of bash and zsh. For bash, you’ll find most of these global settings in the /etc/profile file, the /etc/bashrc file, and various files in the /etc/profile.d/ directory. For zsh, you’ll find these settings in the /etc/zprofile, /etc/zshrc, and /etc/zshenv files. (Note that zsh also references the same /etc/profile file that bash references.) If you were to open one of these files at this point, you likely won’t understand much of what’s going on in them. That’s okay, because for now that doesn’t matter. But, you’ll easily be able to find where the environmental variables are set, because the variable names are all in upper-case letters.

Now, let’s say you don’t like a particular setting. For example, let’s say that you want to customize your command-line prompt to your own liking. Here on my Fedora workstation, my bash prompt looks like this:

[donnie@fedora ~]$

The format of the prompt is determined by the PS1 environmental variable. We can see the PS1 settings like this:

[donnie@fedora ~]$ echo $PS1
[\u@\h \W]\$
[donnie@fedora ~]$

Here’s the breakdown of what you’ve just seen:

• [: This is a literal character, which is the first thing we see in the prompt.
• \u: This causes the current user’s username to appear.
• @: This is another literal character.
• \h: This causes the first component of the machine’s hostname to appear.
• \W: This causes the name of the current working directory to appear. Note that the upper-case W doesn’t cause the entire pathname to appear.
• ]: This is another literal character.
• \$: This causes the $ to show for all normal users, and the # to appear for the root user.

A while ago, I said that we can use the \ to force the shell to interpret a metacharacter as a literal character. Here though, we see another use for the \. When configuring the PS1 parameters, the \ indicates that we’re about to use a macro command. (Think of a macro as a command that runs when you perform some simple action, such as hitting a specific key or clicking on a specific button.)

Now, let’s say that we want the entire path of the current working directory to appear, along with the current date and time. To do that, we’ll replace the \W with \w, and add the \d and \t macros, like this:

[donnie@fedora ~]$ export PS1="[\d \t \u@\h \w]\$"
[Wed Aug 09 18:14:26 donnie@fedora ~]$

Note that I had to surround the new parameter within a pair of quotes so that the shell would interpret the metacharacters properly. Also, note what happens when I cd into a down-level directory:

[Wed Aug 09 18:14:26 donnie@fedora ~]$cd /etc/profile.d/
[Wed Aug 09 18:29:15 donnie@fedora /etc/profile.d]$

Substituting the /w for the /W causes the entire path of the current working directory to show up.

When you configure the PS1 parameter from the command-line, the new settings will disappear as soon as you either log out from the machine or close the terminal window. To make the setting permanent, just edit the .bashrc file that’s in your home directory. Add the export PS1="[\d \t \u@\h \w]$ " line to the end of the file, and you’ll see the new prompt the next time you either log into the machine or open a new terminal window.

There are still a lot more ways to customize the command prompt that I haven’t shown you. For a more complete list, see the reference that I provided in the Further Reading section. Also, note that I’ve only covered how to do this with bash, because zsh uses different command prompt parameters. (I’ll show you all about that in Chapter 22, Using the Z Shell.)

I can read your mind, and can see that you’re wondering what environmental variables have to do with shell scripting. Well, it’s just that sometimes you’ll need to have your script perform a specific action that depends upon the value of a specific environmental variable. For example, let’s say that you only want the script to run for the root user, and not for any unprivileged user. Since we know that the user identification number for the root user is 0, we can write code that allows the script to run if the UID variable is set to 0, and to prevent the script from running if the UID is set to anything other than 0.

And by the way, I apologize if it seems a bit creepy that I can read your mind.

That does it for our introduction to environmental variables. Let’s now take a quick look at programming variables.