Scripts & Automation: Teach the Machine Your Routine

That's the idea. Everything you've typed at the prompt this entire course could be pasted into a file and replayed. Let's build one — a tiny backup script — and hit every ingredient along the way.

#!/usr/bin/env bash
# Back up the notes folder with today's date in the name.

BACKUP_NAME="notes-backup-$(date +%F)"

mkdir -p backups
cp -r notes "backups/$BACKUP_NAME"
echo "Backed up notes to backups/$BACKUP_NAME"

Three new things in eight lines:

Now make it runnable. Two steps, both from chmod: give the file execute permission, then run it with the explicit ./ path. The .sh on the end is convention for humans and editors — the execute bit and that first line are what actually run it.

chmod +x backup.sh
./backup.sh
# Backed up notes to backups/notes-backup-2026-07-12

The ./ is there for the reason that section gave: a bare backup.sh sends the shell hunting through PATH, and this folder deliberately isn't on it. Running it this way also starts a child shell, so the script's variables and any cd inside it are gone the moment it exits — exactly the distinction Your Shell Config drew.

Arguments: $1 makes it reusable

Inside a script, $1 is the first argument the script was handed — the words after its name (Getting Help), numbered in the order they arrived, so $2 is the second. One change turns our notes-only script into a back-up-anything script:

#!/usr/bin/env bash
# Usage: ./backup.sh <folder>

TARGET="$1"
BACKUP_NAME="$TARGET-backup-$(date +%F)"

mkdir -p backups
cp -r "$TARGET" "backups/$BACKUP_NAME"
echo "Backed up $TARGET to backups/$BACKUP_NAME"

./backup.sh notes
# Backed up notes to backups/notes-backup-2026-07-12

./backup.sh recipes
# Backed up recipes to backups/recipes-backup-2026-07-12

How agents deliver a file: the here-doc

Watch a coding agent create a file and you'll see one shape over and over — a whole file, delivered in a single command:

cat <<'EOF' > backup.sh
#!/usr/bin/env bash
mkdir -p backups
cp -r notes "backups/notes-$(date +%F)"
EOF

Read the first line in three parts. cat you know. <<'EOF' is a here-document: "feed the lines that follow straight in as input, until a line that says exactly EOF." And > backup.sh is the redirection from Text & Pipes, catching all of it in a file. The delimiter is any word you like — EOF ("end of file") is convention, not a keyword. The quotes around it are the single-quote rule from Paths in a new costume: quoted, every $ between the markers travels into the file literally — which is what you want when the script's own $(date +%F) should run later, not now. Unquoted, the shell expands them all before the file is even written. One habit to take from this: the lines between the markers are the file — audit them exactly the way you'd audit the script they're about to become. (The playground doesn't speak here-docs; this one is for reading agent transcripts, and for your real machine.)

Try It: Automate the Backup

Now make it reusable. A hard-coded path backs up one folder; $1 backs up whatever you name. Same audit habit applies — read the script before you run it.

Try It: One Script, Any Folder

Every command, when it finishes, hands the shell a number called its exit code: 0 means success, and anything else (1 to 255) means some flavor of failure. Which number it picks is each command's own business and means nothing outside that command, so there's no master table to go hunting for — only zero-or-not-zero travels between commands. You never see it unless you ask — the special variable $? holds the exit code of the last command:

ls notes
# recipes.md  todo.md
echo $?
# 0            <- found it, success

ls no-such-folder
# ls: cannot access 'no-such-folder': No such file or directory
echo $?
# 2            <- non-zero: it failed, and it said so

On its own that's a curiosity. It earns its keep with the three chaining operators, which decide whether the next command runs based on the last one's exit code:

true && echo "ran"        # ran        (true exits 0)
false && echo "ran"       #            (nothing - && skips after failure)
true || echo "ran"        #            (nothing - || skips after success)
false || echo "ran"       # ran

# The pattern you'll use every day:
npm test && npm run deploy
# tests pass  -> deploy runs
# tests fail  -> deploy never happens

# And the three-operator shape, read left to right:
npm test && npm run deploy || echo "something failed"

true and false in the first four lines are real little programs whose entire job is to exit 0 and 1 — which is what makes that truth table runnable rather than illustrative. The last line has a catch. The chain runs left to right and neither operator outranks the other, so the || is not paired off against the && — it fires whenever the command immediately before it failed. Tests pass, deploy fails, and the message prints anyway. Useful here, but it is not the one-branch-or-the-other shape it looks like. (Package Managers covers what npm run deploy is running.)

One number decides which branch runs — the same mechanism behind every CI pipeline (continuous integration: servers that build and test your code for you, automatically).

The classic horror story: ; where && belonged

Why does the choice of connector matter so much? Because of lines like this one, which has genuinely destroyed home directories. The target sits in /tmp, the machine's shared scratch space (Paths), so emptying a folder inside it is a perfectly ordinary thing to want:

# THE TRAP - a semicolon runs the rm NO MATTER WHAT:
cd /tmp/build ; rm -rf *
# If /tmp/build doesn't exist, cd FAILS... and rm -rf * runs
# anyway - in whatever directory you were standing in. Maybe ~.

# THE SAFE VERSION - && only deletes if the cd succeeded:
cd /tmp/build && rm -rf *
# cd fails -> the chain stops -> nothing is deleted.

And here's why this little number matters beyond one-liners: the entire automated world runs on exit codes. CI pipelines decide pass-or-fail by the exit code of your test command — and GitHub, which stores projects and runs those tests every time someone sends up new code, draws its green checkmark to mean "everything exited 0." Coding agents watch exit codes the same way: run a command, read $?, and decide whether to continue, retry, or fix. When your agent says "the tests failed, let me look" — it didn't read your mind. It read an exit code. Scripts join the same game: a script's own exit code is that of its last command, so scripts can chain scripts, and the whole tower stands on one convention. Zero means go.

Try It: Deploy Only on Green