Environment variables in Linux CLI - Deep Dive

Overview - Environment variables

What is it?

Environment variables are named values stored by the operating system that programs and scripts can use to get information about the system or user settings. They act like small notes that tell software important details, such as where to find files or what language to use. These variables exist outside of the program code but influence how programs run. They are essential for configuring software without changing the program itself.

Why it matters

Without environment variables, every program would need to be manually configured inside its code or by editing many files, making software harder to manage and less flexible. They allow users and programs to share important settings easily and consistently. For example, they help programs find where to save files or connect to the internet. This makes computers more organized and software easier to use and automate.

Where it fits

Before learning environment variables, you should understand basic command-line usage and how programs run in a shell. After mastering environment variables, you can learn about shell scripting, process management, and configuration files to automate tasks and customize your system.

Mental Model

Core Idea

Environment variables are like labeled envelopes that hold important information programs can open to learn how to behave without changing their code.

Think of it like...

Imagine a kitchen where each chef (program) gets a recipe card (environment variable) with special instructions like the oven temperature or ingredient locations. The chefs don’t change their recipes but follow the card to cook correctly.

┌───────────────────────────┐
│       Operating System     │
│ ┌───────────────────────┐ │
│ │ Environment Variables  │ │
│ │  ┌───────────────┐    │ │
│ │  │ PATH=/usr/bin │    │ │
│ │  │ LANG=en_US    │    │ │
│ │  │ HOME=/home/me │    │ │
│ │  └───────────────┘    │ │
│ └───────────────────────┘ │
│           ↓               │
│    ┌───────────────┐      │
│    │   Program     │      │
│    │  (reads vars) │      │
│    └───────────────┘      │
└───────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What are environment variables

Concept: Introduce the basic idea of environment variables as named pieces of information stored by the system.

In Linux, environment variables are strings with a name and a value. You can see them by typing the command 'printenv' or 'env' in the terminal. For example, 'HOME' shows your home directory path. These variables help programs know about your system and preferences.

Result

Running 'printenv HOME' shows your home directory path, like '/home/username'.

Understanding that environment variables are simple name-value pairs stored by the system helps you see how programs get configuration without hardcoding.

2

Foundation

How to view and set variables

Concept: Learn commands to display and create environment variables in the shell.

Use 'echo $VARIABLE_NAME' to see a variable's value, like 'echo $PATH'. To set a variable temporarily, use 'VARIABLE_NAME=value', for example, 'MYVAR=hello'. To make it available to child processes, use 'export MYVAR'.

Result

After 'export MYVAR=hello', running 'echo $MYVAR' outputs 'hello'.

Knowing how to view and set variables lets you control program behavior and customize your environment interactively.

3

Intermediate

Difference between shell and environment variables

🤔Before reading on: do you think all variables you set in the shell are automatically environment variables? Commit to yes or no.

Concept: Distinguish between shell-only variables and environment variables that child processes inherit.

Variables you create without 'export' exist only in the current shell session and are not passed to programs started from it. Using 'export' marks them as environment variables, making them visible to child processes. For example, 'VAR=1' is shell-only, but 'export VAR=1' makes it an environment variable.

Result

A program started from the shell sees only exported variables, not shell-only ones.

Understanding this difference prevents confusion about why some variables are visible to programs and others are not.

4

Intermediate

Common environment variables and their roles

🤔Before reading on: do you think the PATH variable controls where programs look for commands or where files are saved? Commit to your answer.

Concept: Introduce important standard environment variables like PATH, HOME, LANG, and SHELL.

PATH tells the shell where to find executable programs. HOME points to your user directory. LANG sets language and locale preferences. SHELL shows which shell you are using. These variables influence how commands run and how programs behave.

Result

Changing PATH can make new commands available without typing full paths.

Knowing common variables helps you understand and control your system's behavior effectively.

5

Intermediate

Persisting environment variables across sessions

🤔Before reading on: do you think setting a variable in the terminal stays after reboot or logout? Commit to yes or no.

Concept: Learn how to make environment variables permanent by adding them to configuration files.

Variables set in the terminal last only for that session. To keep them, add 'export VAR=value' lines to files like '~/.bashrc', '~/.profile', or '~/.bash_profile'. These files run when you start a new shell or log in, setting variables automatically.

Result

After adding 'export MYVAR=hello' to '~/.bashrc' and restarting the terminal, 'echo $MYVAR' outputs 'hello'.

Knowing how to persist variables saves time and ensures consistent environments across sessions.

6

Advanced

Environment variables in scripts and subprocesses

🤔Before reading on: do you think a script can change the parent shell's environment variables? Commit to yes or no.

Concept: Understand how environment variables behave when scripts run and how subprocesses inherit them.

When you run a script, it gets a copy of the environment variables from the parent shell. Changes inside the script affect only that script and its children, not the parent shell. To change the parent shell's environment, you must 'source' the script using '. scriptname' or 'source scriptname'.

Result

Running 'script.sh' that sets VAR=1 won't change VAR in the parent shell, but sourcing it will.

Knowing this prevents confusion about why variables set in scripts sometimes don't persist after the script ends.

7

Expert

Security and pitfalls of environment variables

🤔Before reading on: do you think environment variables are safe to store sensitive data like passwords? Commit to yes or no.

Concept: Explore risks and best practices when using environment variables for sensitive information.

Environment variables can be seen by any process running under your user or by system logs, so storing secrets like passwords or keys in them can be risky. Use dedicated secret management tools or files with restricted permissions instead. Also, be careful with variable names to avoid conflicts or accidental overwrites.

Result

Storing secrets in environment variables can expose them unintentionally, causing security breaches.

Understanding security risks helps you protect sensitive data and avoid common vulnerabilities in automation.

Under the Hood

When a shell starts, it loads environment variables from system and user configuration files into a table in memory. Each process inherits a copy of this table from its parent. When a program requests a variable, the system looks it up in this table. Setting or exporting variables updates this table for the current process and its children. Variables are passed as strings, and the system does not enforce types or structure.

Why designed this way?

This design allows flexible configuration without changing program code. Passing variables as strings keeps the system simple and compatible across programs and languages. Inheriting variables from parent to child processes ensures consistent environments while isolating changes to each process. Alternatives like hardcoded settings would be inflexible and error-prone.

Parent Shell
  │
  ├─ Environment Table (VAR=val, PATH=...)
  │
  ├─ Fork ──▶ Child Process
  │           └─ Copy of Environment Table
  │
  └─ Export VAR=val updates Parent Table
              └─ New children inherit updated table

Myth Busters - 4 Common Misconceptions

Quick: do you think setting a variable without export makes it an environment variable? Commit to yes or no.

Common Belief: If I set a variable like VAR=1, it automatically becomes an environment variable.

Reality: Only variables marked with 'export' become environment variables visible to child processes; others stay local to the shell.

Why it matters: Without exporting, child programs won't see the variable, causing unexpected behavior or bugs.

Quick: do you think environment variables can change the parent shell's variables when set inside a script? Commit to yes or no.

Common Belief: Running a script that sets environment variables changes them in my current shell.

Reality: Scripts run in a subshell; changes to environment variables inside them do not affect the parent shell unless sourced.

Why it matters: Misunderstanding this leads to confusion when variables seem not to persist after scripts run.

Quick: do you think environment variables are secure places to store passwords? Commit to yes or no.

Common Belief: It's safe to store sensitive data like passwords in environment variables.

Reality: Environment variables can be exposed to other processes or logs, making them insecure for secrets.

Why it matters: Storing secrets in environment variables can lead to security leaks and unauthorized access.

Quick: do you think changing PATH only affects the current command or all future commands? Commit to your answer.

Common Belief: Changing PATH once affects all commands forever.

Reality: Changing PATH affects only the current shell session and its children; it resets after logout or reboot unless saved.

Why it matters: Not persisting PATH changes causes confusion when commands stop working after restarting the terminal.

Expert Zone

1

Some environment variables are read once at program start and cached, so changing them later has no effect on running programs.

2

The order of directories in PATH matters; the shell uses the first matching executable it finds, which can cause subtle bugs if duplicates exist.

3

Locale variables like LANG and LC_ALL interact in complex ways; setting LC_ALL overrides others but is discouraged for permanent use.

When NOT to use

Environment variables are not suitable for storing large data, complex configurations, or highly sensitive secrets. Use configuration files, databases, or secret management systems like Vault instead. Also, avoid relying on environment variables for inter-process communication beyond simple flags or settings.

Production Patterns

In production, environment variables are often managed by container orchestration systems or deployment tools to inject configuration dynamically. They are used to separate code from configuration, enabling the same software to run in different environments without changes. Secrets are usually injected at runtime with restricted access.

Connections

Configuration files

Environment variables complement configuration files by providing dynamic, session-based settings.

Understanding environment variables helps grasp how software separates static configuration (files) from dynamic context (variables).

Process inheritance

Environment variables are passed from parent to child processes during process creation.

Knowing process inheritance clarifies why environment variables behave the way they do across scripts and programs.

Human memory cues

Environment variables act like external memory notes that guide behavior without changing the core program.

Recognizing this connection helps appreciate how external context influences system behavior, similar to how humans use reminders.

Common Pitfalls

#1 Setting a variable without export expecting child processes to see it.

Wrong approach:

MYVAR=hello
./run_script.sh

Correct approach:

export MYVAR=hello
./run_script.sh

Root cause:

Not understanding that only exported variables become environment variables visible to child processes.

#2 Running a script that sets variables and expecting the parent shell to keep those changes.

Wrong approach:

./set_vars.sh
echo $MYVAR

Correct approach:

source ./set_vars.sh
echo $MYVAR

Root cause:

Not realizing scripts run in subshells and do not affect the parent shell environment unless sourced.

#3 Storing passwords directly in environment variables for automation.

Wrong approach:

export DB_PASS='mypassword123'

Correct approach:

Use a secrets manager or read password from a protected file with restricted permissions.

Root cause:

Assuming environment variables are secure storage for sensitive data.

Key Takeaways

Environment variables are simple name-value pairs that programs use to get configuration from the system.

Only variables marked with 'export' become environment variables visible to child processes.

Changes to environment variables inside scripts do not affect the parent shell unless the script is sourced.

Common variables like PATH and HOME control important system behaviors and user preferences.

Environment variables are not secure for storing secrets; use dedicated secret management tools instead.