Reliable Scripts and Scheduling

Introduction

A script that works once on your laptop can fail in surprising ways in production: a variable is empty, a command fails halfway, a temporary file is left behind. This lesson covers habits that make scripts trustworthy.

Strict mode

Put this near the top of serious scripts:

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

• -e exit immediately if a command fails.
• -u treat an unset variable as an error, instead of silently using an empty value.
• -o pipefail make a pipeline fail if any part of it fails, not only the last.

These catch many silent bugs. Without -u, rm -rf "$DIR/" with an empty DIR becomes rm -rf /. With it, the script stops.

Functions and exit codes

log() {
  echo "[$(date +%T)] $*"
}

backup() {
  local src="$1"
  local dest="$2"
  [ -d "$src" ] || { log "No such folder: $src"; return 1; }
  cp -r "$src" "$dest"
  log "Backed up $src"
}

backup ./docs ./backup-docs

local keeps variables inside the function. A function (and a script) reports success with 0 and failure with a non-zero number. exit 2 ends a script with code 2. Callers use if backup ...; then or && and || to react.

Cleanup with trap

Use trap to run code however the script ends, even on an error or Ctrl+C:

tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT

echo "working in $tmp"

mktemp -d creates a unique temporary folder, and the trap deletes it at the end.

Check your scripts

ShellCheck is a free tool that finds common mistakes, such as unquoted variables:

shellcheck backup.sh

Use it often. Also test your script on sample data first, and print what it would do before it does destructive things, a "dry run" mode.

Scheduling with cron

cron runs commands on a schedule. Edit your schedule with:

crontab -e

Each line has five time fields, then the command:

# minute hour day-of-month month day-of-week  command
30 2 * * *      /home/sam/backup.sh
0 9 * * 1       /home/sam/weekly-report.sh
*/15 * * * *    /home/sam/check.sh

• 30 2 * * * runs at 02:30 every day.
• 0 9 * * 1 runs at 09:00 every Monday.
• */15 * * * * runs every 15 minutes.

Cron runs with a minimal environment, so:

• Use full paths to commands and files.
• Send output to a log so you can see problems: ... >> /home/sam/backup.log 2>&1
• Test the script by hand first.

On systems that use systemd, timers are an alternative to cron.

Try it yourself

Take your backup.sh from the last lesson. Add strict mode, a log function, and a trap that cleans up. Run ShellCheck on it, then schedule it with cron to run every day, writing output to a log file.

Summary

• set -euo pipefail, quoted variables and local make scripts safer.
• trap ... EXIT cleans up, and exit codes report success or failure.
• cron schedules jobs, but needs full paths and logging, and ShellCheck finds mistakes early.