← Guide index · Repository home
The shell is both an interactive diagnostic environment and a programming language. Safe work depends on quoting, exit status, pipelines, redirection, and explicit failure handling.
Caution
Inspect targets and understand impact before running privileged or mutating commands. Test changes in a safe environment first.
A maintenance command must find old report files, preview the candidates, archive them, and leave a useful audit trail without deleting the wrong path.
| # | Working principle |
|---|---|
| 1 | Every command returns an exit status; zero conventionally means success. |
| 2 | Quoting controls expansion and protects whitespace or wildcard characters. |
| 3 | A pipeline connects standard output to standard input while standard error remains separate unless redirected. |
set -o errexit -o nounset -o pipefail
report_root="/srv/reports"
find "$report_root" -type f -name '*.csv' -mtime +30 -print
# Inspect the list before replacing -print with a mutating action.
printf 'exit=%s\n' "$?"Commands are examples for observation and controlled testing. Paths, process identifiers, interfaces, and service names must be adapted to the actual host.
- Define the symptom, affected users, and time window.
- Collect the smallest useful set of host and service evidence.
- Form one falsifiable hypothesis.
- Make the least disruptive test or change.
- Verify recovery and record what was learned.
- Use shellcheck for scripts and quote variable expansions by default.
- Print or log targets before bulk file operations.
- Prefer small scripts in version control over undocumented command history.
- Parsing ls output.
- Using rm with an unverified variable or glob.
- Assuming a pipeline failed only when its final command failed.
- What does pipefail change?
- Why does quoting "$variable" matter?
- How would you make a maintenance script idempotent?