COMP 10024 – UNIX Shell Environment Variables (Week 7)

In our previous sessions, we took a “side trip” into the life-cycle of a UNIX process. We learned about forking, exec-ing, and the parent-child relationship. Why? Because without understanding how processes are born, you cannot understand Environment Variables.

1. Local Variables vs. Environment Variables

In the shell, we have two distinct types of variables:

• Shell Variables (Local): These stay inside the current shell. If you start a new program or a “sub-shell,” these variables are invisible to them.
• Environment Variables (Global): These are “exported” variables. When a parent process forks a child, it passes a copy of these variables down to the child.

Think of local variables as your private notes, and environment variables as the “family traits” or instructions you pass down to your children.

2. The Export Mechanism

By default, every variable you create is local. To turn a local variable into an environment variable, we use the export command.

When you type NAME=Joe, you have a local variable. If you then type export NAME, the shell marks that variable. The next time the shell performs a fork(), that variable is packaged up and handed to the new child process.

3. Why do we need them?

Environment variables allow us to share configuration data with every program we run without having to type it out every single time. They provide the “context” or “environment” in which a program operates. Common examples include:

• USER: Your login name.
• HOME: The path to your home directory.
• EDITOR: Your preferred text editor (like vim or nano).
• SHELL: Which shell you are currently using.

4. The King of Variables: PATH

The most important environment variable is PATH. It is a colon-separated list of directories. Every time you type a command like ls or cp, the shell doesn’t automatically know where those programs live.

Instead, the shell looks at the PATH variable and searches those directories, one by one, from left to right, until it finds the executable file. If it reaches the end of the list without finding it, you get the famous error: command not found.

A typical path looks like this:

PATH=/usr/bin:/bin:/usr/sbin:/usr/local/bin

Lab: Master of the Environment

This lab will demonstrate the “inheritance” of variables and how manipulating the PATH can effectively “break” your shell.

Part 1: Proving Inheritance

1. Create a local variable: FAV_FOOD=Pizza
2. Verify it exists: echo $FAV_FOOD
3. Start a sub-shell (a child process): bash
4. Try to see the variable: echo $FAV_FOODResult: It should be empty! The child did not inherit the local variable.
5. Exit the child: exit
6. Now, export it: export FAV_FOOD
7. Go back into a sub-shell: bash
8. Check again: echo $FAV_FOODResult: It appears! The child inherited the exported variable.

Part 2: Inspecting the “Global” List

1. Type env to see all the variables currently being passed to your programs.
2. Notice how many variables are already there (like PWD, USER, and PATH) that you didn’t even create.

Part 3: Breaking the PATH

Warning: This will temporarily make your shell unusable. Don’t worry; closing the terminal will fix it.

1. First, see your current path: echo $PATH
2. Now, “break” it by setting it to something useless: PATH=/tmp
3. Try to run a simple command: lsResult: You should see -bash: ls: No such file or directory. The shell no longer knows where the ls program lives!
4. To fix it without restarting, give the shell the “Absolute Path” to the command: /bin/ls
5. Fix your path by re-assigning it or simply closing and re-opening your terminal window.

Summary Challenge

Try to create a variable called MY_EDITOR, export it, and then check if it appears in the output of the env command. Once you see it there, you’ve successfully modified your shell’s environment!

Categorised in: COMP-10024, Lectures, Portfolio

This post was written by amax