Write Safe Bash Scripts

What you will be able to do

• Explain the five core decisions involved in write safe bash scripts.
• 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

Design Bash scripts with explicit inputs, guarded changes, useful failures, cleanup handling, and syntax and behavior checks before real execution.

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

Explicit inputs

A safe script validates required arguments, files, and environment before performing any state-changing operation. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Check argument count and formats, reject ambiguous values, and print a concise usage message on failure. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: defaults should not guess destructive targets. You should be able to verify this result: invalid input stops before side effects.

03

Quoted data

Quoting expansions prevents spaces and wildcard characters in data from becoming unintended argument boundaries or path patterns. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Double-quote variable and command substitutions unless a specific splitting behavior is required and documented. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: unquoted paths can select multiple targets. You should be able to verify this result: data remains in the intended command argument.

04

Failure handling

Commands can fail in expected ways, so critical steps need explicit status checks and useful diagnostic messages. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Check the operation that controls the next step, report context to standard error, and exit nonzero when completion is unsafe. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: blind continuation can compound partial changes. You should be able to verify this result: failure stops the dependent workflow clearly.

05

Cleanup traps

A trap can arrange cleanup or reporting when a script exits or receives selected signals. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Register cleanup after the temporary resource exists and make the cleanup safe to run more than once. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: a trap does not ensure recovery from all termination. You should be able to verify this result: temporary state is removed on controlled exit paths.

06

Dry-run testing

A dry-run mode reports intended actions without performing them and supports review on representative inputs. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Add syntax checking, test fixtures, and a dry-run path before granting the script elevated access. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: dry-run logic must match real selection logic. You should be able to verify this result: planned targets and actions are reviewable.

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 explicit inputs. Check argument count and formats, reject ambiguous values, and print a concise usage message on failure.

The second decision concerns quoted data. Double-quote variable and command substitutions unless a specific splitting behavior is required and documented.

The third decision concerns failure handling. Check the operation that controls the next step, report context to standard error, and exit nonzero when completion is unsafe.

The fourth decision concerns cleanup traps. Register cleanup after the temporary resource exists and make the cleanup safe to run more than once.

The final decision concerns dry-run testing. Add syntax checking, test fixtures, and a dry-run path before granting the script elevated access. Keep the final output as the baseline for the next task.