Bases du script bash robuste

Prérequis (cursus dev) : terminal, redirections et pipes, mini-projet script.

Pourquoi

L'admin qui répète 10 commandes à la main finit par en rater une. Un script robuste (qui échoue bruyamment au lieu de continuer sur une erreur) transforme les routines en non-événements : backups, deploys, checks.

Concepts

• Garde-fous : set -euo pipefail (échec = stop ; variable non définie = erreur ; échec dans un pipe = échec). Sans eux, le script continue sur l'erreur — le pire mode possible.
• Variables citées : "$var" toujours (sans guillemets, espaces et globs explosent). readonly, ${VAR:?requis} pour exiger.
• Codes retour : 0 = ok, le reste = à interpréter ($? juste après). &&/|| pour enchaîner proprement.
• Idempotence : rejouable sans effet (mkdir -p, ON CONFLICT côté SQL, test -f ||). Un script qu'on n'ose pas relancer est un script raté.

Exemple : squelette de script sérieux

#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="${1:?dossier requis}"
mkdir -p "$BACKUP_DIR"
pg_dump -U monapp monapp | gzip > "$BACKUP_DIR/db-$(date +%F).sql.gz"
test -s "$BACKUP_DIR/db-$(date +%F).sql.gz" || { echo "dump vide !"; exit 1; }

Cas réel

Script de deploy sans set -e : le pull échoue (réseau), le script continue, up -d redémarre l'ancienne version « avec succès », et personne ne remarque pendant 3 jours que la release n'est jamais partie. Avec set -euo pipefail + vérifications : échec bruyant immédiat.

Pièges

• rm -rf "$DIR/" avec DIR vide : rm -rf / théorique — ${DIR:?} obligatoire avant tout rm.
• cd qui échoue puis suite dans le mauvais dossier : cd … || exit 1 ou sous-shell (cd … && …).
• Sorties non testées (curl qui rend une page d'erreur en 200) : vérifier le contenu, pas le code seul (grep -q attendu).

À retenir

set -euo pipefaitoujours, tout cité, idempotent, sorties vérifiées.