Écrire son premier script Bash sous Linux sans partir dans tous les sens

Écrire son premier script Bash sous Linux devient utile dès qu’une tâche revient plusieurs fois : renommer des fichiers, préparer un dossier, lancer une sauvegarde, vérifier un service ou nettoyer des exports. Le piège classique consiste à empiler des commandes trouvées en ligne sans comprendre ce que le script modifie. Un bon script commence au contraire petit, lisible et vérifiable, avec une marge d’erreur suffisante pour apprendre sans abîmer l’environnement, puis s’améliore seulement quand le besoin est clair.

Pour approfondir ce point, consultez Debian 12 vers Debian 13, qui traite plus précisément de passer de debian 12 à debian 13 sans casser son système.

Bash n’est pas réservé aux administrateurs système. C’est un langage d’automatisation pratique pour transformer une suite de commandes en routine fiable. L’objectif du premier script n’est pas d’être élégant. Il doit faire une chose claire, gérer les cas simples, afficher ce qui se passe et s’arrêter proprement quand une condition manque.

Commencer par une tâche réelle, pas par la syntaxe

Le meilleur premier script répond à un besoin concret. Par exemple : créer une arborescence de projet, compresser un dossier, vérifier la présence de fichiers, convertir une série de noms ou lancer une commande avec toujours les mêmes options. Si vous ne pouvez pas décrire le résultat attendu en une phrase, le périmètre est trop large. Un script débutant doit résoudre une gêne réelle, pas démontrer toute la syntaxe Bash. Cette contrainte donne un meilleur code qu’une liste d’exemples sans contexte.

Avant d’écrire, notez la version manuelle : commandes, ordre, fichiers lus et fichiers modifiés. Ce plan court suffit.

Une bonne règle tient en peu de mots : commencez avec un dossier de test. Gardez-la.

Cette préparation peut sembler lente. Elle économise pourtant beaucoup de temps, car les erreurs Bash les plus pénibles viennent souvent d’un chemin mal cité, d’un argument absent ou d’une commande exécutée trop tôt. Le script fiable protège d’abord contre vos propres oublis, puis seulement contre les limites de l’environnement Linux.

Si la tâche touche à des fichiers importants, ajoutez une contrainte dès le départ : le premier essai ne doit rien supprimer. Copie, lecture, affichage, simulation ou création d’un dossier temporaire suffisent pour valider l’idée. Le mode brouillon évite de découvrir une erreur après une commande irréversible.

Le script peut évoluer ensuite. La première version doit surtout rester contrôlable.

Créer le fichier et choisir le bon shebang

Un script Bash est un fichier texte. Sa première ligne peut indiquer l’interpréteur à utiliser. C’est le shebang. Pour un script Bash simple, on rencontre souvent #!/bin/bash ou #!/usr/bin/env bash. La première forme pointe vers un chemin courant ; la seconde cherche Bash dans l’environnement. Le choix importe moins que la cohérence : évitez d’écrire du Bash puis de lancer le fichier avec un autre shell, surtout si vous utilisez des syntaxes propres à Bash.

Pour tester vite, lancez d’abord le fichier avec bash nom-du-script.sh. Les droits viendront ensuite.

#!/usr/bin/env bash

echo "Préparation du dossier de travail"
mkdir -p sortie
echo "Dossier prêt"

Ce script est volontairement simple. Il affiche une étape, crée un dossier si nécessaire et confirme le résultat. Ce n’est pas spectaculaire, mais c’est le bon point de départ : une action visible, sans risque majeur, que vous pouvez relancer sans casser l’environnement. Pour un débutant, l’idempotence compte beaucoup : relancer le script ne doit pas créer un problème nouveau.

Ajoutez un nom clair. Le nom du script est déjà une documentation utile.

Utiliser les variables sans rendre le script fragile

Les variables servent à nommer ce qui peut changer : dossier source, dossier cible, extension, date, option ou message. En Bash, l’affectation ne met pas d’espace autour du signe égal. À l’usage, mettez presque toujours la variable entre guillemets. Cette habitude protège les chemins avec espaces, les valeurs vides et les noms de fichiers moins propres que ceux de vos exemples.

La différence paraît minime. Elle change pourtant le comportement du script. Une variable non citée peut être découpée en plusieurs mots, interprétée comme un motif ou produire une commande inattendue. Pour un débutant, les guillemets sont une ceinture de sécurité. Ils ne résolvent pas tout, mais ils évitent une famille entière d’erreurs difficiles à diagnostiquer, notamment quand un fichier contient un espace, une apostrophe, une valeur vide ou un caractère interprété par le shell.

source_dir="$1"
target_dir="sortie"

if [ -z "$source_dir" ]; then
  echo "Indiquez un dossier source"
  exit 1
fi

Le script lit $1, vérifie la valeur, puis s’arrête proprement si l’argument manque. C’est le bon réflexe.

Ne cachez pas les valeurs importantes. Pendant les tests, affichez le dossier source, le dossier cible et l’action prévue. Vous pouvez réduire ces messages plus tard, mais ils sont précieux au début. La sortie du terminal doit vous aider à comprendre, pas seulement à constater que quelque chose a échoué.

Ajouter une condition pour éviter les actions absurdes

Une condition sert à vérifier l’état du système avant de continuer. Le dossier existe-t-il ? Le fichier est-il lisible ? La commande nécessaire est-elle disponible ? L’utilisateur a-t-il fourni l’argument attendu ? Un script sans condition fonctionne seulement le jour où tout va bien, c’est-à-dire rarement quand il sort de votre dossier de test.

Pour débuter, quelques tests lisibles suffisent : dossier, fichier, chaîne vide, commande disponible.

La condition n’est pas là pour faire joli. Elle vous évite de lancer une copie depuis un dossier inexistant ou de supprimer dans le mauvais emplacement.

Placez les conditions avant les commandes qui modifient le système. C’est une règle simple, mais elle change tout. Vérifier après coup qu’un dossier n’existait pas n’aide pas si le script a déjà créé, déplacé ou supprimé des fichiers au mauvais endroit. Le contrôle préalable doit être visible dans la première moitié du script, avant les copies, suppressions, déplacements ou changements de droits.

Une condition utile se lit presque comme une phrase. Si elle paraît obscure, simplifiez-la.

Lire les arguments au lieu de modifier le script à chaque fois

Les arguments évitent de modifier le code à chaque usage : dossier, extension, nom de fichier ou option simple. Ils rendent le script réutilisable.

Mais les arguments doivent être contrôlés. Affichez un exemple d’usage quand une valeur manque. Un bon message d’erreur vaut mieux qu’un script silencieux.

• Un argument obligatoire doit être testé au début.
• Un chemin doit être cité avec des guillemets.
• Une option dangereuse doit être confirmée ou testée sur une copie.
• Un message d’aide doit montrer la forme attendue de la commande.

Cette discipline rend le script partageable. Une autre personne peut comprendre comment le lancer sans lire toutes les lignes.

Si le script accepte plusieurs options, n’essayez pas tout de suite de reproduire un outil professionnel. Une aide courte suffit : nom du script, arguments attendus, exemple de lancement et rappel des limites. Une aide minimale réduit les erreurs d’usage sans alourdir le code, et vous laisse améliorer le script par étapes.

Boucles, pipelines et fichiers temporaires : rester simple

Les boucles appliquent une action à plusieurs fichiers. Les pipelines enchaînent des commandes sans fichier temporaire.

Pour débuter, préférez une boucle explicite. Elle montre le fichier traité, l’action lancée et le message affiché. Si une commande échoue, vous saurez plus facilement où regarder. La lisibilité compte davantage que la ligne la plus courte, surtout quand vous relirez le script plusieurs semaines plus tard.

for file in "$source_dir"/*.txt; do
  [ -e "$file" ] || continue
  echo "Traitement de $file"
  cp "$file" "$target_dir/"
done

Ce type de boucle doit rester prudent. Le test [ -e "$file" ] || continue évite de traiter un motif vide quand aucun fichier ne correspond. C’est un détail, mais il distingue un script de démonstration d’un script utilisable. Dans Bash, les petits garde-fous valent mieux qu’un commentaire optimiste, parce qu’ils protègent aussi les cas que vous n’avez pas imaginés au moment d’écrire, comme un dossier vide ou une extension absente.

Pour approfondir ce point, consultez linux remove directory, qui traite plus précisément de supprimer un dossier linux sans effacer plus que prévu.

Éviter les commandes dangereuses trop tôt

Certaines commandes ne pardonnent pas. Supprimer, écraser, déplacer en masse, changer des droits ou lancer une commande récursive doit rester hors du premier essai. Si vous devez préparer ce type d’action, commencez par afficher les fichiers concernés. Ensuite seulement, ajoutez l’action réelle derrière une option explicite. Le passage en production d’un script personnel doit être volontaire, jamais automatique.

Un débutant gagne aussi à séparer lecture et modification. Une première version liste les fichiers. Une deuxième copie vers un dossier de sortie. Une troisième renomme ou archive. Cette progression semble prudente, mais elle permet de comprendre chaque effet. Quand le script échoue, vous savez quelle étape regarder.

Ne testez jamais une suppression sur le seul exemplaire d’un fichier. Travaillez sur une copie.

Pour les tâches régulières, créez un petit journal de ce qui a été fait : date, dossier traité, nombre de fichiers, message d’erreur éventuel. Même un simple affichage redirigé vers un fichier peut suffire. La trace d’exécution transforme un script opaque en outil contrôlable, surtout quand il tourne rarement.

Tester avant de faire confiance au script

Un script Bash doit être testé comme un outil qui peut modifier le système. Commencez dans un dossier de copie, avec quelques fichiers sans importance. Testez le cas normal, puis les cas gênants : argument absent, dossier vide, fichier avec espace, absence de droits, commande indisponible. Les cas limites révèlent les faiblesses, parce qu’ils reproduisent les situations qui arrivent forcément sur un vrai poste : nom de fichier inattendu, dossier manquant, droit refusé ou commande absente après une installation minimale.

Ajoutez des messages simples : action prévue, résultat obtenu, raison d’arrêt. Ne laissez pas l’utilisateur deviner seul.

Pour les actions sensibles, prévoyez un mode simulation. C’est une protection simple pour les fichiers importants.

Gardez aussi une trace des erreurs. Un message envoyé vers la sortie d’erreur, ou au minimum une ligne claire dans le terminal, aide à comprendre l’échec. Vous n’avez pas besoin d’un système de logs complet pour un premier script. Mais vous avez besoin de savoir où le script s’est arrêté, quelle entrée il traitait et quelle commande a produit le problème.

Tester n’est pas une étape finale. C’est une manière d’écrire un script que vous assumerez ensuite.

Quand Bash devient le mauvais choix

Bash est excellent pour orchestrer des commandes, manipuler des fichiers et automatiser des gestes système. Il devient moins confortable quand la logique grossit : beaucoup de données structurées, appels API, traitements JSON complexes, tests unitaires, calculs ou interfaces utilisateur. Dans ces cas, Python peut être plus lisible.

Le bon critère est la maintenance. Si vous devez relire le script trois fois pour comprendre un enchaînement de substitutions, de pipelines et de conditions imbriquées, il est peut-être temps de changer d’outil. Un script court rend service ; un script opaque devient une dette, surtout lorsqu’il tourne sur un poste de travail ou un serveur que d’autres personnes utilisent.

Gardez Bash pour les routines de terminal. Pour le reste, choisissez l’outil qui rend l’intention plus claire et durable.

Une méthode simple pour progresser

Votre premier script doit être utile dès aujourd’hui. Choisissez une tâche répétitive, écrivez la version minimale, testez-la sur une copie, ajoutez les conditions nécessaires et seulement ensuite améliorez les messages. Cette progression évite de transformer un apprentissage simple en projet interminable.

La priorité : écrire un script que vous oserez relancer dans trois semaines. Noms explicites, commentaires rares mais utiles, chemins cités, erreurs vérifiées, exemples d’usage. Avec ces bases, Bash devient un outil quotidien, pas une syntaxe intimidante. Vous progressez ensuite en ajoutant une option, une boucle ou un contrôle à la fois, jamais en réécrivant tout d’un coup.

La prochaine action est concrète : créez un dossier de test, copiez seulement les fichiers .txt, puis relancez avec un argument.

Pour approfondir ce point, consultez fichier hosts windows, qui traite plus précisément de fichier hosts windows, le modifier sans casser le dns.