Linux environment variable tips and tricks

Environment variables exist to enhance and to standardize your shell environment on Linux systems. There are standard environment variables that the system sets up for you, but you can also set up your own environment variables, or optionally change the default ones to meet your needs.

[ Free download: Advanced Linux commands cheat sheet. ]

Starting with the env command

If you want to see your environment variables, use the env command and look for the words in all caps in the output's far left. These are your environment variables, and their values are to the right:

 $ env
LS_COLORS=(long output)
LANG=en_US.UTF-8
HISTCONTROL=ignoredups
HOSTNAME=rhel8t
XDG_SESSION_ID=5
USER=khess
SELINUX_ROLE_REQUESTED=
PWD=/home/khess
HOME=/home/khess
SSH_CLIENT=192.168.1.94 53911 22
SELINUX_LEVEL_REQUESTED= XDG_DATA_DIRS=/home/khess/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
SSH_TTY=/dev/pts/1
MAIL=/var/spool/mail/khess
TERM=xterm-256color
SHELL=/bin/bash SELINUX_USE_CURRENT_RANGE=
SHLVL=1
LOGNAME=khess
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000 PATH=/home/khess/.local/bin:/home/khess/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/bin
HISTSIZE=1000
LESSOPEN=||/usr/bin/lesspipe.sh %s _=/usr/bin/env 

I have omitted the output of the LS_COLORS variable because it is so long. Try this command on your system to see what the full output looks like.

Many environment variables are set and then exported from the /etc/profile file and the /etc/bashrc file. There is a line in /etc/profile that reads:

 export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL

Skip to the bottom of list

Image

Download now

To make permanent changes to the environment variables for all new accounts, go to your /etc/skel files, such as .bashrc, and change the ones that are already there or enter the new ones. When you create new users, these /etc/skel files will be copied to the new user's home directory.

Exploring shell levels (SHLVL)

To call the value of a single environment variable, enter the following command, using SHLVL (Shell Level) as an example:

 $ echo $SHLVL 1

This variable changes depending on how many subshells you have open. For example, enter bash twice and then issue the command again:

 $ bash 
$ bash echo $SHLVL 3

A shell level of three means that you are two subshells deep, so type exit twice to return to your regular shell.

[Want to try out Red Hat Enterprise Linux? Download it now for free.] 

Manipulating your PATH variable

The PATH variable contains the search path for executing commands and scripts. To see your PATH, enter:

 $ echo $PATH /home/khess/.local/bin:/home/khess/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

Temporarily change your PATH by entering the following command to add /opt/bin:

 $ PATH=$PATH:/opt/bin
$ echo $PATH /home/khess/.local/bin:/home/khess/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/bin

The change is temporary for the current session. It isn't permanent because it's not entered into the .bashrc file. To make the change permanent, enter the command PATH=$PATH:/opt/bin into your home directory's .bashrc file.

When you do this, you're creating a new PATH variable by appending a directory to the current PATH variable, $PATH. A colon (:) separates PATH entries.

Unraveling $USER, $PWD, and $LOGNAME

I had a theory that I think has been dispelled by my own good self. My theory was that the commands pwd and whoami probably just read and echoed the contents of the shell variables $PWD and $USER or $LOGNAME, respectively. To my surprise, after looking at the source code, they don't. Maybe I should rewrite them to do just that. There's no reason to add multiple libraries and almost 400 lines of C code to display the working directory. You can just read $PWD and echo that to the screen (stdout). The same goes for whoami with either $USER or $LOGNAME.

If you want to have a look at the source code for yourself, it's on GitHub and other places. If you find that these programs (or others) do use shell variables, I'd love to know about it. Admittedly, I'm not that great at reading C source code, so they could very well use shell variables and I'd never know it. They just didn't seem to from what I read and could understand.

Playing the $SHELL game

In this last environment variable overview, I want to show you how the $SHELL variable comes in handy. You don't have to stay in your default shell, which is likely Bash. You can enter into and work in any shell that's installed on the system. To find out which shells are installed on your system, use the following command:

 $ cat /etc/shells /bin/sh /bin/bash /usr/bin/sh /usr/bin/bash

All of those are actually Bash, so don't get excited. If you're lucky, you might also see entries for /bin/tcsh, /bin/csh, /bin/mksh, /bin/ksh, and /bin/rksh.

You can use any of these shells and have different things going on in each one if you're so inclined. But, let's say that you're a Solaris admin and you want to use the Korn shell. You can change your default shell to /bin/ksh using the chsh command:

 $ chsh Changing shell for khess. New shell [/bin/bash]: /bin/ksh Password: Shell changed.

Now, if you type echo $SHELL, the response will be /bin/bash, so you have to log out and log in again to see the change. Once you log out and log in, you will receive a different response to echo $SHELL.

You can enter other shells and echo $SHELL should report your current shell and $SHLVL, which will keep you oriented as to how many shells deep you are.

[ Learn how to manage your Linux environment for success. ]

Setting your own environment variables

You can set your own variables at the command line per session, or make them permanent by placing them into the ~/.bashrc file, ~/.profile, or whichever startup file you use for your default shell. On the command line, enter your environment variable and its value as you did earlier when changing the PATH variable.

Wrapping up

Shell or environment variables are helpful to users, sysadmins, and programmers alike. They are useful on the command line and in scripts. I've used them over the years for many different purposes, and although some of them are probably a little unconventional, they worked and still do. Create your own or use the ones given to you by the system and installed applications. They truly can enrich your Linux user experience.

As a side note on variables and shells, does anyone think that those who program in JSON should only be allowed to use the Bourne Shell? Discuss.