Linux Environment Variables for Beginners

Introduction

Programs often need small pieces of configuration: a home directory, a language, a search path, or an application setting. Linux processes receive many of these values through an environment, a collection of named strings.

This lab builds the idea in layers. You will first create a variable that belongs only to the current shell, then export a variable to child processes, inspect standard variables, extend PATH, and make settings appear in future Zsh sessions. Each step leaves an observable file or command result so you can verify what the shell actually did.

Create and Expand a Shell Variable

In this step, you will create a shell variable and observe how quoting affects expansion.

A shell variable pairs a name with a value inside the current shell. Assignment syntax has no spaces around =. Quoting the value preserves the embedded space:

cd /home/labex/project/environment-lab
course_name="Linux for Noobs"

Prefixing the name with $ asks the shell to expand it to its value:

echo "$course_name"

Double quotes allow expansion and keep the result as one argument. Single quotes preserve the dollar sign literally. Compare them:

printf 'double: %s\n' "$course_name"
printf 'single: %s\n' '$course_name'

Save the expanded value as an observable result:

printf 'course=%s\n' "$course_name" > shell-variable.txt
cat shell-variable.txt

This variable exists only in the current shell unless it is exported.

Observe Child-Process Inheritance

In this step, you will compare an ordinary shell variable with an exported variable inside a child process.

Every command runs in a process. A child process receives exported environment variables from its parent, but it does not receive ordinary shell variables.

Return to the workspace and create one variable of each kind:

cd /home/labex/project/environment-lab
local_message="visible only in this shell"
export SHARED_MESSAGE="visible in child processes"

Create a small Bash child process that prints both names. The quoted heredoc marker prevents the current shell from expanding the variables while writing the script:

cat > inspect-child.sh <<'EOF'
#!/bin/bash
printf 'local=%s\n' "${local_message:-<missing>}"
printf 'shared=%s\n' "${SHARED_MESSAGE:-<missing>}"
EOF
chmod +x inspect-child.sh

Run it and redirect the output to a file, then display the file. Keeping these as separate commands makes it clear which action runs the child process and which action inspects the saved result:

./inspect-child.sh > child-environment.txt
cat child-environment.txt

The ordinary variable appears as <missing>, while SHARED_MESSAGE is inherited. Confirm that the exported name is present in the environment:

env | grep '^SHARED_MESSAGE='

Inspect Standard Environment Variables

In this step, you will inspect standard variables that describe your account, working directory, terminal, and command search path.

Linux shells normally provide useful standard variables:

HOME is your home directory.
USER is your account name.
SHELL is your configured login shell.
PWD tracks the current working directory.
PATH lists command-search directories separated by colons.
TERM describes terminal capabilities to interactive programs.

Display selected values with printenv, which reads exported variables by name:

printenv HOME USER SHELL PWD TERM

PATH is easier to read one entry per line. Send the value through tr to replace every colon with a newline:

printf '%s\n' "$PATH" | tr ':' '\n'

Create a stable report from variables whose expected values are known in this lab:

cd /home/labex/project/environment-lab
printf 'HOME=%s\nUSER=%s\n' "$HOME" "$USER" > standard-environment.txt
cat standard-environment.txt

Extend PATH with a Personal Command

In this step, you will add a personal executable directory to PATH and run a command by name from another directory.

When you enter a command without a slash, the shell searches the directories in PATH from left to right. You can add a personal executable directory without replacing the existing search path.

Create a command named course-status:

mkdir -p "$HOME/bin"
cat > "$HOME/bin/course-status" <<'EOF'
#!/bin/bash
echo "Linux learning environment is ready"
EOF
chmod +x "$HOME/bin/course-status"

Append the directory to the current PATH. Keeping $PATH preserves access to standard commands:

export PATH="$PATH:$HOME/bin"

Ask the shell which file it will execute, then run the command from a different directory:

command -v course-status
cd /tmp
course-status

Save its output in the lab workspace:

course-status > /home/labex/project/environment-lab/path-command.txt

Persist Settings for Future Zsh Sessions

In this step, you will configure future Zsh sessions and distinguish persistent configuration from current-shell state.

Exporting changes the current process and its future children; it does not edit a configuration file. A setting appears in later terminals only when a startup file recreates it. The LabEx Terminal uses Zsh, whose interactive startup file is ~/.zshrc.

Append a clearly marked block. Each export line recreates one environment setting whenever a new interactive Zsh starts. This beginner version keeps the startup file intentionally direct: preserve the existing PATH, then add the personal directory at the end.

cat >> "$HOME/.zshrc" <<'EOF'
## LABEX_ENV_LAB_START
export PROJECT_DIR="$HOME/project"
export PATH="$PATH:$HOME/bin"
## LABEX_ENV_LAB_END
EOF

The source command reads a file in the current shell. Reload .zshrc now so you can use its settings without closing the Terminal:

source "$HOME/.zshrc"

Confirm that the reloaded variable is available:

printf 'PROJECT_DIR=%s\n' "$PROJECT_DIR"

You should see PROJECT_DIR=/home/labex/project. You can also start a new Zsh process to prove that a future session loads the same settings. In zsh -ic, -i requests an interactive shell so .zshrc is read, and -c supplies the command that shell should run. Redirect its two output lines into future-shell.txt, then inspect the file:

zsh -ic 'printf "PROJECT_DIR=%s\n" "$PROJECT_DIR"; command -v course-status' > /home/labex/project/environment-lab/future-shell.txt
cat /home/labex/project/environment-lab/future-shell.txt

The first line should show /home/labex/project; the second should show /home/labex/bin/course-status.

Finally, learn the difference between current state and persistent configuration. Create and remove a temporary environment variable:

export TEMP_NOTE="remove me"
printenv TEMP_NOTE
unset TEMP_NOTE
printenv TEMP_NOTE

The final printenv produces no output and returns a nonzero status because the name no longer exists. unset removes the name from the current shell. If a name is still defined in a startup file, a future shell will recreate it until that configuration line is removed.

Summary

You observed the three mechanisms that are often confused: a shell variable belongs to one shell, export passes a value to child processes, and a startup file recreates settings in future shells. You also inspected standard environment variables, extended PATH without losing existing entries, verified command lookup, and removed temporary state with unset.

Environment Variables in Linux