infra / linux-bash

Scripting bash : les bases

Leçon 61 exercice

Explication

Un script bash n'est rien d'autre qu'une liste de commandes, exactement celles que tu tapes déjà au clavier — la seule différence, c'est qu'elles sont écrites dans un fichier pour être rejouées à volonté. Dès qu'une suite d'actions se répète plus de deux fois, il est temps d'en faire un script : c'est le tout premier pas vers l'automatisation, une compétence centrale du métier de l'infra.

Ce que vous allez apprendre

Écrire un script exécutable avec un shebang correct et le rendre lançable (chmod +x)
Déclarer des variables, lire les arguments passés au script ($1, $@, $#)
Écrire des conditions if/elif/else sans tomber dans le piège classique des espaces manquants
Tester l'existence d'un fichier ou d'un dossier avant d'agir dessus ([ -f ], [ -d ])
Boucler avec for et while pour traiter une liste de fichiers ou répéter une action

Dans quel contexte ?

Un développeur doit déployer la même application sur trois environnements différents (dev, staging, prod), chacun avec sa propre configuration. Plutôt que de retaper les mêmes dix commandes à chaque fois en changeant juste un nom, il écrit un script deploy.sh qui prend l'environnement en argument (./deploy.sh prod) et adapte son comportement en conséquence. C'est exactement la logique que cette leçon construit pas à pas.

Avant même la première commande : le shebang

La première ligne d'un script, #!/usr/bin/env bash, n'est pas un commentaire anodin. C'est une instruction pour le système qui indique quel interpréteur utiliser pour exécuter le reste du fichier.

Sans cette ligne, ou si le fichier n'est pas rendu exécutable avec chmod +x, le script ne se lancera tout simplement pas correctement. C'est souvent la toute première erreur que rencontrent les débutants.

Ensuite, il faut comprendre comment bash voit les variables

Contrairement à des langages comme Python ou JavaScript, bash ne distingue pas vraiment les nombres des textes. Tout est manipulé comme une chaîne de caractères, sauf dans des contextes bien précis comme les comparaisons numériques.

Comparaison	Numérique	Chaîne de caractères
Égalité	`[ "$a" -eq "$b" ]`	`[ "$a" == "$b" ]`
Inférieur	`[ "$a" -lt "$b" ]`	(rare, alphabétique)
Différent	`[ "$a" -ne "$b" ]`	`[ "$a" != "$b" ]`

C'est une source fréquente de bugs pour qui vient d'un autre langage : une variable qui "ressemble" à un nombre reste, pour bash, du texte tant qu'on ne lui dit pas explicitement le contraire.

Prérequis

Cette leçon suppose que tu es à l'aise avec la navigation (cd, ls) et les permissions (chmod), déjà vues dans les leçons précédentes — un script commence toujours par devoir être rendu exécutable.

Une fois les variables comprises, les conditions posent une question surprenante

La syntaxe [ "$1" == "prod" ] déroute souvent au début. En réalité, les crochets sont une commande à part entière, équivalente à test, et non une simple syntaxe du langage.

C'est justement pour ça que les espaces à l'intérieur des crochets sont obligatoires : en oublier un seul (["$1"=="prod"]) casse silencieusement toute la condition, sans message d'erreur clair.

Piège fréquent

Écrire if [ $1 == "prod" ] sans guillemets autour de $1 plante avec l'erreur "unary operator expected" dès que le script est appelé sans argument. Le réflexe systématique : toujours "$1", jamais $1 seul, dans une condition.

Pense aussi à toujours entourer tes variables de guillemets, comme "$1", pour éviter des erreurs si la variable est vide ou contient des espaces.

Le lien avec ce que tu as déjà vu

Cette leçon assemble tout ce que tu as appris jusqu'ici — navigation, permissions, processus — dans un outil réutilisable : le script. C'est la porte d'entrée vers l'automatisation plus avancée (gestion d'erreurs, tableaux, fonctions) que tu approfondiras plus loin dans le cours, une fois les autres commandes système maîtrisées.

Commandes & code

Scripting bash : les bases

#!/usr/bin/env bash
# Le "shebang" ci-dessus dit au système quel interpréteur utiliser.
# Rendre le script exécutable : chmod +x script.sh puis ./script.sh

# Variables : pas d'espaces autour du =, pas de type déclaré
nom="Technologik"
version=1
echo "Bienvenue sur $nom, version ${version}"

# Variables en lecture seule
readonly PI=3.14159

# Entrée utilisateur
read -p "Ton prénom : " prenom
echo "Salut, $prenom !"

# Arguments du script
echo "Nom du script : $0"
echo "1er argument : $1"
echo "2e argument  : $2"
echo "Tous les arguments : $@"
echo "Nombre d'arguments : $#"

# Conditions
if [ "$1" == "prod" ]; then
    echo "Déploiement en production"
elif [ "$1" == "staging" ]; then
    echo "Déploiement en staging"
else
    echo "Environnement inconnu, utilisation de dev par défaut"
fi

# Comparaisons numériques vs chaînes
[ "$a" -eq "$b" ]   # égalité numérique
[ "$a" -lt "$b" ]    # a < b (numérique)
[ "$a" == "$b" ]      # égalité de chaînes
[ -z "$a" ]             # chaîne vide
[ -n "$a" ]               # chaîne non vide

# Tests sur les fichiers
[ -f fichier.txt ]     # existe et est un fichier régulier
[ -d dossier/ ]          # existe et est un dossier
[ -x script.sh ]           # est exécutable
[ -e chemin ]                 # existe (quel que soit le type)

# Boucles
for i in 1 2 3; do
    echo "Itération $i"
done

for fichier in *.log; do
    echo "Traitement de $fichier"
done

count=0
while [ "$count" -lt 5 ]; do
    echo "count = $count"
    count=$((count + 1))
done

# Sortie du script avec un code d'erreur explicite
if [ ! -f "/etc/config.yml" ]; then
    echo "Erreur : fichier de config manquant" >&2
    exit 1
fi
exit 0

Résumé

Un script commence par un shebang (#!/usr/bin/env bash) et doit être exécutable (chmod +x).
$1, $2, $@, $# donnent accès aux arguments passés au script.
[ ] (ou test) sert aux conditions ; attention aux espaces obligatoires à l'intérieur des crochets.

Exercices pratiques

1 disponible

Mission : fiabiliser un script de déploiement multi-environnements

Objectif : Écrire un script bash qui valide ses arguments et ses fichiers avant d'agir, et repérer les pièges classiques d'un script mal protégé.

Contexte

Ton équipe déploie la même application sur dev, staging et prod avec un script deploy.sh qui prend l'environnement en argument (./deploy.sh prod). Un premier jet du script plante de façon imprévisible : parfois avec une erreur cryptique, parfois en silence. Ta mission est de le rendre robuste.

Résoudre l’exercice →