shell-safety

Why this is a skill on a machine with no shell of its own

Everything you run goes through one tool call and lands in a terminal on a screen somebody is watching. That makes a bad command visible, which is good — and permanent, which is why it is worth writing it correctly the first time.

The failures that bite hardest

A pipeline hides its own failure. cmd | tee out.txt exits 0 when cmd died, because the exit code belongs to tee. A tool that returns success for a command that failed is exactly the silent failure this project ranks above a crash. Where the result matters, run the step on its own and read its exit code, or start with set -o pipefail:

run_command   bash -c 'set -euo pipefail; apt-get update && apt-get -y install nginx'

-e stops on the first error, -u makes an unset variable an error instead of an empty string, -o pipefail makes a pipeline fail when any part of it does.

An unquoted variable is a bug waiting for a space. rm -rf $DIR with DIR empty is rm -rf /, and with DIR="/tmp/my files" it removes two things that are not what you meant. Quote every expansion: rm -rf "$DIR". The habit costs two characters and removes a whole class of accident.

A glob that matches nothing expands to itself. rm *.log in a directory with no logs tries to remove a file literally called *.log — usually harmless, occasionally not. Check first: list_directory is a tool and it answers exactly this without running anything.

cd that fails keeps going. cd /some/path; rm -rf ./* deletes the wrong directory's contents when the cd failed. Use &&, never ;, between a move and an action: cd /some/path && rm -rf ./*.

Before anything destructive, do it twice

Once to see, once to do:

run_command   find /var/cache -name '*.tmp' -mtime +30          # look
run_command   find /var/cache -name '*.tmp' -mtime +30 -delete  # then act

apt -s simulates. rsync -n dry-runs. rm -i is useless here because nobody can answer the prompt — that is what ask_human is for, before the command.

rm -rf is a decision

Say the path out loud before you run it, and prefer an absolute path to a relative one, because a relative path means whatever the working directory is and you did not set it. If a person is present and the target is not obviously scratch, ask. This is the one command where being slow is cheap and being fast is unrecoverable.

Chaining, and where it stops being safe

An approval you were given for a command does not extend past a && — the person approving apt update did not approve what follows it. Keep an approved command to one thing, and where a sequence genuinely belongs together, say so when you ask.

Long commands are jobs, and jobs need their output

job_start returns an id; job_output and job_status are how you read what happened. A job you started and never read is a command you did not run, as far as knowing the result goes — and job_wait timing out means wait again, not start again.