Environment Variables and Shell Startup

What you will be able to do

• Explain the five core decisions involved in environment variables and shell startup.
• Choose the narrow Linux command or method that matches a stated operational need.
• Interpret command output as evidence before deciding whether to change system state.
• Apply an observe, act, verify, and recover workflow to a realistic Linux task.

01

Build the Operating Model

Distinguish shell variables from exported environment, understand Bash startup files, and diagnose configuration without editing all profile files.

Reliable Linux work separates observation, decision, action, and verification. That order keeps a command from becoming a guess and makes each result useful for the next decision.

Begin in a disposable lab or a recoverable environment. Record the active user, working directory, target, and baseline output before any command that can change system state.

02

Shell variables

A shell variable belongs to the current shell and is not automatically included in child-process environments. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Assign the variable, inspect it in the current shell, and decide whether child processes genuinely need it. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: unquoted values can undergo shell expansion. You should be able to verify this result: a value exists in the current shell.

03

Exported environment

Export marks a shell variable so later child processes receive it in their environments. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Export only values required by child programs and verify with a newly launched child shell. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: secrets in environment can be exposed to processes. You should be able to verify this result: child processes inherit the exported value.

04

Command lookup path

The PATH variable lists directories Bash searches in order when a command name contains no slash. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Inspect PATH entries, add only trusted directories, and confirm which executable resolves after a change. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: an unsafe early directory can shadow trusted commands. You should be able to verify this result: command lookup follows the intended directory order.

05

Login startup

A Bash login shell reads a defined sequence of profile files and stops at the first user profile it finds. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Determine whether the shell is a login shell before choosing the profile file that should hold a setting. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: editing all profile files creates conflicting settings. You should be able to verify this result: login-specific configuration loads from one profile.

06

Interactive startup

An interactive non-login Bash shell normally reads the user's `.bashrc` file. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Place interactive aliases and prompt behavior in `.bashrc`, then test from a fresh interactive shell. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: noninteractive scripts may not read bashrc. You should be able to verify this result: interactive settings load in new terminal shells.

07

Apply One Controlled Change

Start from the read-only commands that reveal identity, scope, and current state. Write the expected result before entering a modifying command, including which files, processes, accounts, or connections may be affected.

Make one narrow change and stop. If the output reports an error or an unexpected target, preserve that evidence and return to inspection instead of adding unrelated commands.

Repeat the original observation after the action. A successful command status is useful, but the real completion signal is the intended state plus the absence of an unintended side effect.

08

Complete the Evidence Loop

A good terminal record answers four questions: what was observed, why one action was selected, exactly what changed, and how the result was verified. A screenshot without command context answers fewer questions than saved text output.

Test both the expected success and one safe failure condition. This confirms that the procedure recognizes a wrong path, missing permission, invalid input, stopped service, or unavailable endpoint instead of silently continuing.

Finish by restoring the lab baseline when the task was experimental. For an operational change, record the final state and the reversal step so later work begins from a known boundary.

09

Recap Before Practice and Prove

The first decision concerns shell variables. Assign the variable, inspect it in the current shell, and decide whether child processes genuinely need it.

The second decision concerns exported environment. Export only values required by child programs and verify with a newly launched child shell.

The third decision concerns command lookup path. Inspect PATH entries, add only trusted directories, and confirm which executable resolves after a change.

The fourth decision concerns login startup. Determine whether the shell is a login shell before choosing the profile file that should hold a setting.

The final decision concerns interactive startup. Place interactive aliases and prompt behavior in `.bashrc`, then test from a fresh interactive shell. Keep the final output as the baseline for the next task.