Ajoutez de l’intelligence et de la robustesse à vos scripts

Jusqu'à présent, vos créations suivaient un chemin linéaire : elles exécutaient les commandes de la première à la dernière ligne, sans se poser de questions. Cependant, dans un environnement professionnel dynamique, les conditions changent constamment. Vous allez maintenant :

• utiliser des conditions pour que votre script vérifie son environnement avant d'agir,

• déployer des boucles pour appliquer automatiquement un traitement à plusieurs fichiers d'un coup,

• intercepter les erreurs système pour stopper l'outil avant le moindre dégât.

Contrôlez l’exécution d’un script avec des conditions

Votre outil interactif fonctionne à merveille et vos collègues commencent à l'adopter. Mais ce matin, dans la précipitation, l'un d'eux renseigne un nom de fichier avec une faute de frappe ("systeme.log" au lieu de "system.log"). Conséquence : le script tente d'ouvrir le vide, affiche un message d'erreur système et poursuit son exécution aveuglément !

Pour que votre script devienne un outil professionnel de confiance, il doit réagir correctement si un fichier manque ou si un paramètre est incorrect. C'est ici qu'interviennent les conditions.

Cette prise de décision s'appuie très souvent sur des opérateurs de test, encadrés par des crochets  [ ]  . Ils permettent d'évaluer votre environnement. Si l'opérateur  -e  (pour exists) vérifie l’existence d’un élément, l'opérateur   -f  (pour file) va plus loin : il s'assure que l'élément est bien un fichier classique (et non un dossier ou un autre type d'élément système).

Arthur, votre référent technique, insiste souvent sur ce point :

Lancer un traitement aveuglément, c'est le meilleur moyen de générer des erreurs en cascade. Un jour, un script a tenté de traiter un dossier vide et a corrompu toute notre base de données. Depuis, on applique une règle d'or : on s'assure toujours que la donnée est là avant d'y toucher.

Grâce à cette logique conditionnelle, vous serez capable de construire un outil qui saura adapter son comportement, voire afficher un message d'aide convivial si le collègue s'est trompé. Retenez bien ceci : un script robuste vérifie avant d’agir.

Voyons comment traduire cette logique en lignes de commandes et l'intégrer pas-à-pas dans notre éditeur.

Dans cette vidéo, on a :

• introduit la structure conditionnelleif / then / elsepour orienter le comportement du script,

• testé la nature d'un élément avec l'opérateur-fpour s'assurer qu'il s'agit d'un fichier classique avant de le traiter,

• personnalisé les messages de retour pour guider le collègue qui a fait une erreur de saisie,

• empêché l'exécution de commandes inutiles lorsque la condition initiale n'est pas remplie.

Votre script sait désormais réagir correctement face à un fichier invalide. Il peut maintenant franchir une nouvelle étape : traiter plusieurs fichiers en appliquant cette même logique à chacun d’eux.

Répétez automatiquement des actions avec des boucles

Votre script sécurisé est un vrai soulagement pour l'équipe, il ne plante plus si on se trompe de fichier. Mais face à l'afflux de données, un nouveau défi se présente. Ce matin, un collègue a dû analyser 50 logs distincts générés pendant la nuit. S'il doit lancer votre script 50 fois de suite en tapant chaque nom de fichier à la main, l'automatisation perd tout son intérêt !

Pour traiter un grand volume de données en une seule fois, vous avez besoin de boucles.

Couplée à la fameuse variable spéciale$@   (qui, pour rappel, englobe la totalité des arguments tapés après le nom de votre script), la boucle for devient redoutable. Vous pouvez fournir autant de fichiers que vous le souhaitez dans le terminal, le script s'adaptera dynamiquement à la longueur de la liste.

Arthur, votre référent technique, résume parfaitement l'état d'esprit à adopter face à ces tâches :

Si vous vous surprenez à taper la même commande plus de trois fois d'affilée dans votre terminal, c'est qu'il est temps d'écrire une boucle. L'informatique doit travailler pour nous, pas l'inverse ! 

Grâce à cette structure, une boucle remplace des dizaines de commandes répétées et rend le code de votre script considérablement plus court et plus clair.

Voyons comment transformer notre script pour qu'il traite des lots entiers de fichiers d'une seule traite, sans jamais s'arrêter.

Dans cette vidéo, on a :

• introduit la structure en bouclefor / in / do / donepour répéter des actions sur des éléments multiples,

• utilisé la variable globale$@pour capturer une quantité infinie d'arguments au lancement,

• créé une variable temporaire (ici$FICHIER) pour manipuler chaque élément un par un à l'intérieur de la boucle,

• exécuté le script sur un lot de fichiers en une seule commande depuis le terminal.

Gérez les erreurs et sécurisez l’exécution du script

Vos boucles fonctionnent à merveille, mais que se passe-t-il si une commande échoue en plein milieu. Par exemple, si le script tente de lire un fichier protégé ? Par défaut, Bash affiche l'erreur, mais passe aveuglément à la ligne suivante.

Pour éviter ce scénario, vous devez gérer les codes de retour. Chaque commande exécutée laisse derrière elle une information sur son résultat. Cette information est stockée dans la variable spéciale$?, qui contient le code de retour de la commande précédente :

• 0= Succès total.

• Tout autre chiffre (1,2...) = Erreur.

Selon le contexte, un script peut adopter deux comportements :

1. s’arrêter immédiatement en cas d’erreur critique pour éviter tout risque, ou

2. continuer son exécution en signalant simplement les éléments problématiques.

Le bon choix dépend de ce que vous cherchez à faire.

En combinant la lecture de ce code avec la commande exit, vous pouvez forcer l'arrêt de l'outil avant la catastrophe :

cat fichier_critique.txt

cat fichier_critique.txt

if [ $? -ne 0 ]; then
  echo "Erreur de lecture. Arrêt immédiat."
  exit 1
fi

# ... (suite du traitement du script) ...
echo "Traitement terminé."
exit 0

Vérifier chaque commande avec unif  peut devenir fastidieux. C'est là qu'intervient le filet de sécurité global :set -e. Placé tout en haut du script (juste sous le shebang), il ordonne au script de s'arrêter net à la toute première erreur rencontrée, quelle qu'elle soit.

Pour bien comprendre pourquoi cette sécurisation est importante, regardons ce qu'il se passe concrètement à l'écran lorsqu'on compare un script "aveugle" et un script sécurisé. 

Retenez cette règle d'or de l'automatisation : un script doit dire ce qu’il fait et si tout s’est bien passé.

À vous de jouer

Contexte 

Votre script est désormais utilisé par plusieurs membres de l’équipe pour analyser des fichiers texte contenant l’état des serveurs.

Cependant, certaines erreurs apparaissent : oubli d’argument, faute de frappe dans le nom d’un fichier, ou encore tentative de traitement de fichiers inexistants. Ces situations rendent le script difficile à utiliser et peu fiable.

Votre objectif est donc d’améliorer ce script afin qu’il devienne plus robuste et capable de gérer ces imprévus de manière autonome.

Consignes

1. Modifiez votre script existant (ou utilisez le script de référence fourni) pour vérifier qu’au moins un argument est passé lors de son exécution.

#!/bin/bash

echo "Voici le contenu du fichier : $1"

cat $1

2. Si aucun argument n’est fourni, affichez un message clair indiquant l’usage attendu, puis arrêtez immédiatement le script.

3. Utilisez une boucle pour traiter l’ensemble des fichiers passés en argument.

4. Pour chaque fichier, vérifiez qu’il existe bien avant de tenter de le lire.

• • Si le fichier existe, affichez un message indiquant qu’il est en cours de traitement, puis affichez son contenu.

  • Si le fichier n’existe pas, affichez un message d’erreur explicite, puis continuez le traitement avec les autres fichiers sans interrompre le script.

En résumé

• La structure conditionnelleif / then / elsepermet à un script de vérifier son environnement avant d’agir, notamment grâce aux opérateurs de test comme-fpour s’assurer qu’un fichier existe et est valide.

• Les bouclesfor / in / do / donepermettent de répéter automatiquement un traitement sur plusieurs éléments, en exploitant notamment la variable$@pour parcourir tous les arguments fournis.

• L’utilisation d’une variable temporaire dans une boucle facilite le traitement individuel de chaque fichier tout en conservant un code clair et lisible.

• Chaque commande renvoie un code de retour stocké dans$?, et son analyse permet de détecter une erreur et d’interrompre proprement le script avecexit.

• L’instructionset -erenforce la robustesse globale en arrêtant immédiatement le script à la première erreur rencontrée, garantissant ainsi un comportement fiable et sécurisé.

Jusqu’à présent, votre script permettait d’exécuter des commandes automatiquement. Mais votre équipe ne veut pas seulement “exécuter des commandes” : elle a besoin d’indicateurs clairs pour comprendre rapidement une situation. La prochaine étape est d’analyser et transformer des données directement depuis vos scripts Bash pour produire des résultats synthétiques.