Linux Environment Variables Explained: Shell Variables, export, and PATH

You set a value in your terminal, start a program, and the program behaves as though the value does not exist. The missing step may be how that setting reaches the program.

Linux environment variables are named values supplied to a program when it starts. Programs can use them to find commands, choose language settings, or receive application-specific configuration.

This lesson explains the difference between a value stored in your shell and a value passed to another program. You will observe that boundary without editing configuration files or restarting services.

🧠 Start with the Shell and the Program

The shell is the program that interprets commands you type. Bash is one common shell on Linux. A terminal provides the interface; the shell decides what your command means.

When the shell launches another program, that program runs as a process: an executing instance of a program. The process that starts it is its parent, and the newly started process is its child.

A variable such as SA_LESSON_MODE=practice contains a name and a text value. The name alone has no special power. A real application must be written to read that name and interpret its value.

For example, inventing FAST_MODE=yes does not make arbitrary software faster. Configuration works only when the program recognizes the setting.

Shell Variables and Environment Variables

Assigning a value gives the shell something to remember. Exporting marks that value for inclusion when the shell launches commands.

There is one useful detail: variables Bash inherits from its own environment are already marked for export. Assigning a new value to one does not remove that marking.

For the exact inheritance rules, see the Bash environment documentation.

🔍 Inspect One Setting at a Time

To ask what PATH value a newly launched command receives, run:

printenv PATH

printenv prints the named variable from its own environment. Because your shell launched it, this is a useful check of what the shell passes onward.

An illustrative result is:

/usr/local/bin:/usr/bin:/bin

Your directories may differ. Focus on the colon-separated entries rather than expecting this exact output.

This command does not inspect a web server that is already running. It also does not list variables held only inside your shell. The GNU printenv documentation describes its output and return codes.

How PATH Helps the Shell Find Commands

Typing ls does not tell the shell where the executable file is located. For an external command named without a slash, PATH supplies directories to search in order.

With the example above, the search begins in /usr/local/bin, then checks /usr/bin, then /bin. PATH contains directories, not a list of individual executable files.

Bash also has commands implemented inside the shell, called builtins, and supports functions. Those can be selected before an external executable search. Bash can remember previously resolved executable locations, too.

A command containing a slash supplies a path directly. For example, ./report refers to a file named report in the current directory. It does not request the usual PATH search.

Finding an executable is only the first step. The file still needs to be runnable, and its application configuration must still be valid. The Bash command lookup reference explains this distinction.

🧪 Mini Lab: Follow a Value into a Child Process

1. Open a Practice Shell

Start a nested Bash session that skips its usual interactive startup files. Your original shell remains underneath it.

bash --noprofile --norc

The prompt may change. This shell still inherits an environment; skipping startup files does not mean starting with no variables.

Clear our demonstration name inside this practice shell so an inherited value cannot affect the exercise:

unset SA_LESSON_MODE

There is normally no output. This removes only the named variable from the practice shell.

2. Store a Value and Read It in the Shell

Create a variable, then ask the shell to insert its value into a printed line:

SA_LESSON_MODE=practice
printf '%s\n' "$SA_LESSON_MODE"

Expected output:

practice

Keep the assignment together: there are no spaces around =. The $ requests the variable’s value. Double quotes keep that expansion together as one argument, including when a value contains spaces.

printf uses %s to print the supplied text and \n to finish the line. This proves the shell can read the value; it does not prove the value was exported.

3. Ask an External Program to Read It

Now launch a separate program and ask it for the same variable:

printenv SA_LESSON_MODE

Expect no output. The variable exists in the shell, but this newly launched program did not receive it.

GNU printenv also returns status 1 when a requested variable is missing. A return status is a small result code a command leaves for its caller. Here, that result is expected evidence—not a broken installation.

4. Export and Repeat

Mark the existing variable for export, then launch a fresh reader:

export SA_LESSON_MODE
printenv SA_LESSON_MODE

Expected output:

practice

The comparison is the lesson: the first reader received no value; the second received one after you changed the export marking.

5. Override One Launch

Supply a different value to one external command, then launch another reader normally:

SA_LESSON_MODE=inspection printenv SA_LESSON_MODE
printenv SA_LESSON_MODE

Expected output:

inspection
practice

The first launch used its temporary override. The next launch received the practice shell’s existing value.

6. Leave the Practice Shell

Return to your original shell:

exit

The practice shell ends. Its variable changes do not flow back into the shell that started it. Run this once to leave the nested session.

Why Changing a Variable Does Not Update Everything

Environment inheritance has a direction. A parent supplies values when starting a child; the child can then maintain its own values.

Imagine two application processes started with a label of practice. Changing the launching shell’s label afterward does not rewrite either application’s environment. A third application launched later can receive the new value.

Similarly, a child cannot update its parent’s environment just by changing its own variables. This separation explains why the lab’s settings disappeared when you returned to the original shell.

The Bash execution environment reference describes this separation.

Why a Service Can Have Different Settings

A system service is normally started by the service manager, not by your interactive terminal. It therefore does not automatically receive variables you just exported in that terminal.

The existing lesson on creating a systemd service introduces explicit environment configuration. That configuration belongs to the service’s launch context.

Before changing a service, identify which setting the application actually requires and how its launcher supplies that setting. A successful terminal experiment proves the terminal case; it does not establish what the service received.

Scheduled tasks have the same environment boundary. Cron does not simply replay your interactive shell, so variables and command paths that work in a terminal may be missing when a scheduled command runs. See the Linux cron jobs guide for crontab schedules, execution environments, output handling, and troubleshooting.

Does export Make a Setting Permanent?

No. Export controls inheritance, not storage on disk.

Future shells can recreate settings by reading startup files. Which files Bash reads depends on how it starts. An interactive non-login Bash normally reads ~/.bashrc; a login Bash follows a different startup sequence.

A shell running a script also has different rules. Consequently, putting a line into one startup file does not make it universal application configuration.

This lesson deliberately avoids editing those files. First understand the scope you need: one command, one terminal session, future interactive shells, or a managed service. Then use the configuration mechanism appropriate to that scope.

Consult Bash startup file rules before making a persistent shell change.

⚠️ Common Mistakes