Shell Scripting & Automation

Why Script Instead of Typing Commands

A script turns a fragile sequence of manual steps into something repeatable, reviewable, and safe to run at 3am by someone who isn't you. Every production automation pipeline — CI/CD, cron jobs, deployment tooling — is built on the same shell-scripting fundamentals.

Anatomy of a Script

#!/usr/bin/env bash
set -euo pipefail

echo "Backing up $1..."

• The shebang (#!/usr/bin/env bash) tells the kernel which interpreter runs the rest of the file. Using env bash instead of a hardcoded /bin/bash path is more portable across systems where bash lives in a different location.
• set -e — exit immediately if any command fails, instead of silently continuing
• set -u — treat any unset variable as an error, catching typos before they cause damage
• set -o pipefail — a pipeline's exit code reflects the first failing command, not just the last one

Variables and Quoting

name="alice"        # no spaces around =
echo "$name"         # always quote expansions

Unquoted variables are word-split and glob-expanded by the shell. A variable holding my file.txt becomes two separate arguments (my and file.txt) if left unquoted — a classic source of scripts that "work on my machine" and break on real data.

Positional parameters: $1, $2, ... are the script's arguments; $@ is all of them; $# is the count; $0 is the script's own name.

Conditionals

if [ -d "$SRC" ]; then
  echo "Directory exists"
else
  echo "Missing: $SRC" >&2
  exit 1
fi

Common test operators: -f (regular file exists), -d (directory exists), -z (string is empty), -eq/-ne (numeric equality).

A case statement branches cleanly on multiple string patterns without a long if/elif chain:

case "$env" in
  prod)  echo "careful!";;
  staging|dev) echo "safe to experiment";;
  *) echo "unknown environment"; exit 1;;
esac

Loops

for env in dev staging prod; do
  echo "Deploying to $env"
done

while read -r line; do
  echo "Processing: $line"
done < input.txt

while read -r line; do ... done < file is the safe way to process a file line-by-line — it doesn't word-split or glob-expand each line, unlike for line in $(cat file).

Functions

backup_dir() {
  local target="$1"
  tar -czf "${target}.tar.gz" "$target"
}

local scopes a variable to the function — without it, every variable is global and can silently clobber a caller's state.

Exit Codes

Exit codes are how scripts communicate success/failure to whatever calls them — if my_script.sh; then ... branches on exactly this.

Common Pitfalls

• Unquoted variables causing word-splitting (rm $DIR/* with an unset or empty $DIR can expand dangerously)
• Assuming == works the same in every shell — it's a bash-ism, POSIX sh only guarantees =
• set -e doesn't always do what people expect inside conditionals or the middle of a pipeline — test your assumptions
• Forgetting execute permission (chmod +x script.sh) before trying to run a script directly