By Donald A. Tevault
Variables are an important part of shell scripting, just as they are for every programming language. Simply put, a variable defines a location in system memory that holds a value for later use. This value can be a text string, a number, a filename, or the output of a command. The nice thing about variables is that you can assign a value to one once, and then re-use that value as many times as you like by simply referencing the name of the variable. There are several types of variables, and in this post we’ll look at environmental variables.
As the name suggests, environmental variables help define the operating system environment. They’re used by the shell, running services, and sometimes even by normal user programs. Many environmental variables are pre-defined on every Linux or Unix system. To see the whole list of environmenal variables, use the env command, like so:
[donnie@almalinux9 ~]$ env
SHELL=/bin/bash
HISTCONTROL=ignoredups
HISTSIZE=1000
HOSTNAME=almalinux9
PWD=/home/donnie
LOGNAME=donnie
XDG_SESSION_TYPE=tty
MOTD_SHOWN=pam
HOME=/home/donnie
LANG=en_US.UTF-8
. . .
. . .
PATH=/home/donnie/.local/bin:/home/donnie/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
SELINUX_LEVEL_REQUESTED=
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/donnie
SSH_TTY=/dev/pts/0
BASH_FUNC_which%%=() { ( alias;
eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot $@
}
_=/usr/bin/env
[donnie@almalinux9 ~]$
Okay, this isn’t really the complete list, because I had to cut some out of the middle due to space considerations. But, it’s enough for you to see what’s going on. Anyway, I want you to note here that the names of all environmental variables are always in all upper-case letters. This helps you tell at a glance if a variable is an environmental variable or a normal shell scripting variable.
If you want to see the value of just one environmental variable, use the echo command, and prepend a dollar sign to the front of the variable name. For example, to see which user is logged into the system, just do this:
[donnie@almalinux9 ~]$ echo $USER
donnie
[donnie@almalinux9 ~]$
You can access the value of an environmental variable from within a shell script, like this:
#!/bin/bash
if [ $USER == donnie ] ; then
echo "$USER can use this script."
echo "I'll send this to a text file for $USER". > "$USER"_file.txt
else
echo "$USER cannot use this script."
fi
Here, I’m using an if..else construct to see whether I (donnie) am logged in, or if someone else is. Note that I am allowed to run this script, but nobody else is.
In the second echo statement, I’m sending output to a text file that will have my username in its file name. Here’s how it looks when I run the script from my own account:
[donnie@almalinux9 ~]$ ./user_test.sh
donnie can use this script.
[donnie@almalinux9 ~]$
Now, let’s see if the script created the text file, and verify that it contains the correct contents:
[donnie@almalinux9 ~]$ ls -l donnie_file.txt
-rw-r--r--. 1 donnie donnie 42 Nov 23 15:06 donnie_file.txt
[donnie@almalinux9 ~]$ cat donnie_file.txt
I'll send this to a text file for donnie.
[donnie@almalinux9 ~]$
Now, let’s see what happens if Mr. Tux, my black-and-white tuxedo kitty, tries to run the script:
[mrtux@almalinux9 ~]$ ./user_test.sh
mrtux cannot use this script.
[mrtux@almalinux9 ~]$
It looks like Mr. Tux is just out of luck.
In rare occasions, you might need to modify the value of a pre-defined environmental variable. For example, let’s say that you’ve installed a program from a third-party source. Many times, third-party developers will store their program files in the /opt/ directory, instead of in the normal /usr/bin/ or /usr/sbin/ directories. The problem with that is that, by default, the /opt/ directory isn’t set in the PATH variable, as you see here:
[donnie@almalinux9 ~]$ echo $PATH
/home/donnie/.local/bin:/home/donnie/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
[donnie@almalinux9 ~]$
Let’s say that the executable file for my third-party program is in the /opt/newprogram/ directory. With the default PATH setting, you would have to invoke this program like this:
[donnie@almalinux9 ~]$ /opt/newprogram/newprogram.sh
This is your new program.
[donnie@almalinux9 ~]$
Typing the entire path to the program can get a bit tiresome if you have to do it often. The good news is that you can modify a configuration file in your home directory to add this directory to your PATH setting. On a Red Hat-type operating system, such as AlmaLinux, you would edit the .bashrc file. Open the .bashrc file in your preferred text editor, and find this line:
PATH="$HOME/.local/bin:$HOME/bin:$PATH"
Now, make it look like this:
PATH="$HOME/.local/bin:$HOME/bin:/opt/newprogram:$PATH"
To make this take effect, close your terminal window, and then open it back up. You’ll now be able to invoke the program as you would normally.
[donnie@almalinux9 ~]$ newprogram.sh
This is your new program.
[donnie@almalinux9 ~]$
Okay, very cool. This will definitely make things easier.
Although most evironmental variables are pre-defined, there may be times when you’ll want to create your own. Let’s say that you need to use an AI tool to help you with your work, and you’d prefer to use an AI agent from the command-line. For example, let’s say that you want to use gemini-cli, which is a command-line front end for Google Gemini. Before you can use it, you’ll need to log into your Google account and obtain a Gemini API key. You’ll then need to export the GEMINI_API_KEY environmental variable so that the gemini-cli program can use it, as you see here:
┌──(kali㉿kali)-[~]
└─$ export GEMINI_API_KEY=eeiialkAdlk28jl3iADGeakl!ll3P469alABi
┌──(kali㉿kali)-[~]
└─$
(Note that this is not my real Gemini API key.)
After you export this key, you’ll be able to use the Gemini service. The only slight problem is that this command, along with the API key, will get stored in your shell’s history file. So, even though the GEMINI_API_KEY will disappear from your login session as soon as you either log out or close the terminal window, it will remain in the history file in your home directory. The history file is persistent, even after you reboot your machine. If you walk away from your machine without locking your session, some unauthorized person could steal your key with a simple history command, like so:
┌──(kali㉿kali)-[~]
└─$ history | tail
1994 sudo ip netns exec ns3 iw dev vw3 info
1995 ./vwifi-tool
1996 cd
1997 clear
1998 sudo apt update
1999 sudo apt dist-upgrade
2000 exit
2001 history | export
2002 history | grep export
2003 export GEMINI_API_KEY=eeiialkAdlk28jl3iADGeakl!ll3P469alABi
┌──(kali㉿kali)-[~]
└─$
To prevent a command from getting saved to the history file, hit the space bar once before you enter the command.

Buy The Ultilmate Linux Shell Scripting Guide now, via my Amazon link!
In this post, I showed you how environmental variables work on Linux and Unix operating systems, and how they can sometimes help you with your shell scripting. In the next blog post, we’ll look at how to create and use normal shell scripting variables. I’ll see you there.