Fonctions, arguments et options

Prérequis : cours précédents.

Pourquoi

Un script de 200 lignes linéaires ne se teste pas, ne se réutilise pas, ne se relit pas. Fonctions + options (--dry-run !) = script maintenable et sans surprise.

Concepts

• Fonctions : backup_db() { …; } + local pour les variables (sans local, tout est global et se marche dessus). return = code (0-255), pas de données (echo/stdout pour ça).
• Arguments : $1, $@ (tous, cités !), $# (nombre). Vérifier le nombre + usage (usage() >&2; exit 2).
• Options : getopts (courtes -n) ou parsing manuel --dry-run/--force. DRY-RUN d'abord : tout script destructif s'essaie à blanc.
• Logs : log() { echo "[$(date +%FT%T)] $*"; } + exec >>log 2>&1 optionnel. Un script muet est indéboggable.

Exemple : script avec options

#!/usr/bin/env bash
set -euo pipefail
DRY_RUN=0
while [[ $# -gt 0 ]]; do case "$1" in
  --dry-run) DRY_RUN=1; shift ;;
  *) echo "usage: $0 [--dry-run] DIR"; exit 2 ;;
esac; done
run() { if (( DRY_RUN )); then echo "[dry-run] $*"; else "$@"; fi; }

Cas réel

Script de purge « testé » directement en prod (pas de dry-run) : pattern trop large, 3 jours de backups partis. Depuis : --dry-run par défaut presque, destructif = double confirmation + log.

Pièges

• Variables globales partout : collision entre fonctions — local systématique.
• return de données (return "$gros_texte") : tronqué à 0-255. echo/stdout pour les données.
• Options après les positionnels : convention = options d'abord, sinon getopts se perd.

À retenir

Fonctions + local, usage + vérif args, --dry-run pour le destructif, logs horodatés.