Vous tapez les mêmes commandes dix fois par jour : vérifier l’espace disque d’un serveur, copier des fichiers, lire la fin d’un journal. Chaque manipulation à la main, c’est une occasion de se tromper et du temps perdu. Un script Bash, c’est exactement ça en mieux : une suite de commandes enregistrée dans un fichier, qu’on relance d’un seul mot, à l’identique, autant de fois qu’on veut. À la fin de ce tutoriel, vous aurez écrit, rendu exécutable et lancé votre premier outil — un script qui affiche un état du système — et vous saurez pourquoi chaque ligne est là.
C’est le premier maillon d’un fil rouge qu’on déroule sur toute la série : Boubacar, développeur web freelance à Dakar, gère les sites de plusieurs petits clients. Plutôt que de refaire les mêmes gestes à la main, il se construit une boîte à outils Bash dans un dossier ~/atelier/. On commence aujourd’hui par le tout premier outil.
🎯 Ce que vous allez apprendre
- Écrire un script Bash dans un fichier, le rendre exécutable et le lancer de trois façons différentes ;
- Comprendre le rôle du shebang et pourquoi
#!/usr/bin/env bashest plus portable que#!/bin/bash; - Déclarer et utiliser des variables, capturer la sortie d’une commande, et afficher proprement avec
echoetprintf; - Lire un argument passé au script et éviter le piège n°1 du débutant : les guillemets manquants.
🛠️ Ce que vous allez construire
Un script info-systeme.sh qui affiche en un coup d’œil le nom de la machine, l’utilisateur courant, la date, l’espace disque restant et l’uptime — la première brique de la boîte à outils de Boubacar. Au lieu de taper cinq commandes, il en tapera une seule : ./info-systeme.sh.
Prérequis
- Un système Linux ou macOS (ou WSL sur Windows). Test express : si vous savez ouvrir un terminal et exécuter
lsetcd, vous êtes prêt. Sinon, lisez d’abord Ligne de commande Linux : tutoriel pas-à-pas. - Bash installé. Vérifiez avec
bash --version— au moment d’écrire, la version stable est Bash 5.3 (juillet 2025), mais tout ce tutoriel fonctionne dès Bash 4. - Un éditeur de texte :
nano(le plus simple),vim, ou VS Code. - ⏱️ Temps estimé : ~25 minutes.
Étape 1 — Préparer l’atelier et écrire la première ligne
Avant d’écrire du code, on range. Un script perdu dans le dossier Téléchargements est un script qu’on ne retrouve jamais. On crée un dossier dédié à la boîte à outils, et on s’y place. C’est là que vivront tous les scripts de la série.
mkdir -p ~/atelier
cd ~/atelier
nano info-systeme.sh
mkdir -p crée le dossier atelier dans votre répertoire personnel (~) ; l’option -p évite une erreur si le dossier existe déjà. cd vous y déplace, et nano ouvre un éditeur vide prêt à recevoir le script. Vous devriez voir une fenêtre d’édition avec, en bas, des raccourcis comme ^O (enregistrer) et ^X (quitter).
Tapez maintenant ces deux lignes :
#!/usr/bin/env bash
echo "Bonjour depuis mon premier script !"
La première ligne, qui commence par #!, s’appelle le shebang. Ce n’est pas un commentaire ordinaire : c’est une instruction pour le système. Elle dit « pour exécuter ce fichier, utilise l’interpréteur Bash ». La seconde ligne affiche un message à l’écran avec echo. Enregistrez avec Ctrl+O puis Entrée, et quittez avec Ctrl+X.
✅ Point d’étape — Vous avez un fichier
info-systeme.shdans~/atelier. Pour vérifier :ls -l ~/atelierdoit le lister. Si le fichier n’apparaît pas, c’est que nano l’a enregistré ailleurs — relanceznanodepuis~/atelier.
Étape 2 — Comprendre le shebang (et pourquoi env)
Le shebang mérite qu’on s’y arrête, parce que c’est la source d’innombrables « ça marche chez moi mais pas chez le client ». Deux écritures circulent : #!/bin/bash et #!/usr/bin/env bash. La première suppose que Bash se trouve exactement dans /bin/bash. C’est vrai sur la plupart des Linux, mais faux ailleurs : sur de nombreux BSD, Bash est dans /usr/local/bin/bash, et un script avec un mauvais chemin échoue net.
#!/usr/bin/env bash
La forme avec env demande au système « trouve bash dans le PATH et lance-le ». Elle s’adapte donc à l’emplacement réel de Bash, quelle que soit la machine. C’est la forme recommandée pour un script qu’on partage ou qu’on déploie sur des serveurs variés — exactement le cas de Boubacar, qui travaille sur son portable puis sur les VPS de ses clients.
Un détail crucial pour notre public : sur macOS, le /bin/bash du système est resté bloqué à la version 3.2 (gelée en 2007 pour des raisons de licence). Le shell par défaut de macOS est d’ailleurs zsh depuis Catalina. Si vous écrivez du Bash moderne sur un Mac sans avoir installé un Bash récent (via Homebrew), certaines fonctions de la série ne marcheront pas. La forme env aide à pointer vers le bon Bash.
Étape 3 — Rendre le script exécutable et le lancer
Un fichier texte ne « s’exécute » pas tout seul : il faut donner au système la permission de le traiter comme un programme. C’est le rôle du bit d’exécution, qu’on pose avec chmod.
chmod +x info-systeme.sh
./info-systeme.sh
chmod +x ajoute le droit d’exécution. Le ./ devant le nom est obligatoire : il dit « le script est ici, dans le dossier courant », car par sécurité le dossier courant n’est pas dans le PATH. Vous devriez voir s’afficher Bonjour depuis mon premier script !. Si oui, félicitations : le système a bien lu votre shebang, lancé Bash, et exécuté la ligne echo.
Il existe deux autres façons de lancer un script, utiles à connaître :
bash info-systeme.sh # lance explicitement Bash sur le fichier (pas besoin du bit +x)
source info-systeme.sh # exécute les lignes DANS le shell courant (rare, cas particuliers)
La méthode bash fichier.sh ignore le shebang et n’exige pas le droit d’exécution — pratique pour tester vite. source (ou son alias .) est différent : il n’ouvre pas de nouveau processus, il exécute les commandes dans votre session actuelle. On le réserve aux fichiers de configuration ; pour un script normal, on utilise ./.
✅ Point d’étape —
./info-systeme.shaffiche le message. Si vous obtenezPermission denied, c’est que lechmod +xn’a pas été fait. Si vous obtenezbash: ./info-systeme.sh: No such file or directoryalors que le fichier existe, vérifiez le shebang (un chemin Bash invalide donne ce message trompeur).
Étape 4 — Des variables pour ne pas se répéter
Un script qui n’affiche qu’un texte fixe a peu d’intérêt. Le vrai pouvoir vient des variables : des étiquettes qui retiennent une valeur. On en déclare une en collant le nom, le signe = et la valeur, sans espace autour du = — c’est la règle qui surprend tout le monde au début.
#!/usr/bin/env bash
auteur="Boubacar"
projet="Atelier web"
echo "Script maintenu par $auteur"
echo "Projet : $projet"
Pour lire une variable, on préfixe son nom d’un $. Bash remplace alors $auteur par sa valeur avant d’exécuter la ligne. Notez bien : auteur="Boubacar" (déclaration, pas de $) mais echo "$auteur" (lecture, avec $). Un espace autour du = casserait tout : auteur = "Boubacar" ferait croire à Bash que auteur est une commande à lancer.
Le plus utile, c’est de capturer la sortie d’une commande dans une variable, avec la syntaxe $(...) appelée substitution de commande. C’est ce qui va donner vie à notre outil :
machine=$(hostname)
utilisateur=$(whoami)
date_jour=$(date "+%A %d %B %Y")
Ici, $(hostname) exécute la commande hostname et range son résultat dans la variable machine. Idem pour l’utilisateur courant et la date formatée. Le format +%A %d %B %Y donne quelque chose comme « lundi 12 mai 2026 ». On ne code donc jamais ces valeurs en dur : elles s’adaptent à la machine où tourne le script.
Étape 5 — Assembler l’outil complet
On a toutes les briques : shebang, variables, substitution de commande, affichage. On les assemble en un script lisible. On ajoute df -h pour l’espace disque et uptime pour la durée de fonctionnement, et on soigne la présentation avec printf, plus précis que echo pour aligner.
#!/usr/bin/env bash
#
# info-systeme.sh — affiche un état rapide de la machine.
# Boîte à outils Atelier — tutoriel 1.
machine=$(hostname)
utilisateur=$(whoami)
date_jour=$(date "+%A %d %B %Y, %H:%M")
disque=$(df -h / | awk 'NR==2 {print $4 " libres sur " $2}')
duree=$(uptime -p)
printf '===== État de %s =====\n' "$machine"
printf 'Utilisateur : %s\n' "$utilisateur"
printf 'Date : %s\n' "$date_jour"
printf 'Disque (/) : %s\n' "$disque"
printf 'Allumée : %s\n' "$duree"
La ligne du disque mérite un mot : df -h / affiche l’occupation de la partition racine en format lisible, et awk 'NR==2 {print $4 " libres sur " $2}' isole la 2ᵉ ligne (la 1ʳᵉ étant l’en-tête) pour n’en garder que l’espace libre ($4) et la taille totale ($2). On reviendra longuement sur awk dans un tutoriel dédié de la série. Lancez ./info-systeme.sh : vous devez voir un petit tableau récapitulatif. Sur une machine fraîchement démarrée, uptime -p affichera par exemple up 14 minutes.
✅ Point d’étape — Le script affiche cinq lignes propres avec des valeurs réelles. Si
uptime -prenvoie une erreur, votre système est ancien : remplacez paruptimetout court. Si la ligne disque est vide, vérifiez quedfetawksont installés (ils le sont sur tout Linux standard).
Étape 6 — Lire un argument et le piège des guillemets
Pour finir, rendons l’outil paramétrable. Un script reçoit ses arguments dans des variables spéciales : $1 est le premier argument, $2 le deuxième, et ainsi de suite. $0 contient le nom du script lui-même. Ajoutons la possibilité de saluer un nom passé en argument.
nom="${1:-tout le monde}"
printf '\nRapport généré pour : %s\n' "$nom"
La syntaxe ${1:-tout le monde} est une valeur par défaut : « prends $1, mais s’il est vide ou absent, mets tout le monde à la place ». Ainsi ./info-systeme.sh Awa affichera « Rapport généré pour : Awa », tandis que ./info-systeme.sh sans argument affichera « Rapport généré pour : tout le monde ». Plus de plantage quand l’argument manque.
Voici le piège qui mordra tout débutant un jour : toujours mettre une variable entre guillemets quand vous l’affichez ou la passez à une commande. Sans guillemets, si un argument contient une espace, Bash le découpe en plusieurs morceaux.
nom="Awa Diallo"
echo $nom # Bash voit DEUX arguments : "Awa" et "Diallo"
echo "$nom" # Bash voit UN seul argument : "Awa Diallo" ✅
Dans le premier cas, l’espace n’est pas catastrophique pour un simple echo, mais avec une commande comme rm ou cp, ce découpage peut effacer le mauvais fichier. La règle d’or, qu’on répétera dans toute la série : une variable, des guillemets, sauf raison explicite de ne pas en mettre.
✅ Point d’étape final —
./info-systeme.sh Awaajoute une ligne « Rapport généré pour : Awa ». Votre premier outil est complet et paramétrable. Gardez-le : on l’enrichira au fil de la série.
🐞 Pièges fréquents
| Symptôme / erreur | Cause probable | Correctif |
|---|---|---|
Permission denied |
Le bit d’exécution n’est pas posé | chmod +x info-systeme.sh |
command not found sur auteur |
Espaces autour du = dans la déclaration |
Écrire auteur="..." sans espace |
La variable affiche $nom littéralement |
Guillemets simples '...' autour de la variable |
Utiliser des guillemets doubles "..." |
No such file or directory alors que le fichier existe |
Shebang invalide (mauvais chemin Bash) ou fins de ligne Windows (CRLF) | Vérifier le shebang ; convertir avec dos2unix info-systeme.sh |
| Un nom à espace découpé en deux | Variable non protégée par des guillemets | Toujours "$variable" |
🌍 Adaptation au contexte ouest-africain
Pas besoin d’un serveur coûteux pour apprendre : Bash tourne sur n’importe quelle machine Linux, y compris un vieux portable reconverti ou un Raspberry Pi à moins de 40 000 FCFA. Sous Windows, le sous-système WSL2 donne un vrai Bash gratuit, sans dual-boot. Et puisque la connexion coûte cher et tombe parfois, sachez que Bash et tous les outils utilisés ici (echo, df, awk, date) sont déjà installés : vous pouvez écrire et tester vos scripts entièrement hors-ligne. Le script info-systeme.sh est d’ailleurs parfait pour un coup d’œil rapide à un VPS mutualisé bon marché avant un déploiement, là où chaque méga-octet de disque compte.
✅ Récapitulatif
Vous venez d’écrire votre premier outil Bash de bout en bout. Vous savez créer un fichier de script, poser le shebang #!/usr/bin/env bash et expliquer pourquoi la forme env est plus portable, rendre le fichier exécutable avec chmod +x et le lancer avec ./. Vous savez déclarer des variables (sans espace autour du =), les lire avec $, capturer la sortie d’une commande avec $(...), donner une valeur par défaut avec ${1:-...}, et — le réflexe le plus important — protéger vos variables par des guillemets doubles. La boîte à outils de Boubacar a sa première brique.
🧾 Aide-mémoire
| Élément | Rôle |
|---|---|
#!/usr/bin/env bash |
Shebang portable : trouve Bash via le PATH |
chmod +x script.sh |
Rend le script exécutable |
./script.sh |
Lance le script du dossier courant |
nom="valeur" |
Déclare une variable (pas d’espace autour du =) |
"$nom" |
Lit une variable, protégée des espaces |
$(commande) |
Capture la sortie d’une commande |
${1:-defaut} |
Argument $1 avec valeur par défaut |
printf '%s\n' "$x" |
Affichage précis et formaté |
💪 À vous de jouer
Enrichissez info-systeme.sh pour qu’il affiche aussi la charge mémoire (commande free -h) et qu’il signale un avertissement si l’utilisateur courant est root. Indice : $utilisateur contient déjà le nom de l’utilisateur.
Voir une solution
memoire=$(free -h | awk 'NR==2 {print $3 " utilisés sur " $2}')
printf 'Mémoire : %s\n' "$memoire"
if [ "$utilisateur" = "root" ]; then
printf '⚠️ Attention : vous êtes connecté en root.\n'
fi
On reverra en détail le if et les tests dans le prochain tutoriel ; pour l’instant, retenez la forme if [ "$x" = "y" ]; then ... fi.
Tutoriels frères
- Variables, conditions et tests en Bash — donner un cerveau à vos scripts avec
if,[[ ]]et les codes de sortie. - Boucles et traitement de fichiers en Bash — répéter une action sur des dizaines de fichiers sans effort.
Pour aller plus loin
- 🔝 Retour au guide principal : Bash scripting : le guide complet.
- Prochain tutoriel conseillé : Variables, conditions et tests.
- Manuel de référence GNU Bash (source officielle) : gnu.org/software/bash/manual.
FAQ
Q : Faut-il l’extension .sh pour un script Bash ?
R : Non, elle est purement conventionnelle. Le système se fie au shebang, pas à l’extension. Mais .sh aide à repérer les scripts d’un coup d’œil, alors on la garde par habitude.
Q : Quelle différence entre sh et bash ?
R : sh désigne un shell POSIX minimal ; bash est un sur-ensemble bien plus riche. Sur beaucoup de systèmes, /bin/sh pointe vers un shell réduit (dash). Si votre shebang est #!/bin/sh, les fonctions spécifiques à Bash (comme [[ ]]) ne marcheront pas. D’où l’intérêt de déclarer explicitement bash.
Q : Mon script marche avec bash script.sh mais pas avec ./script.sh. Pourquoi ?
R : Deux causes habituelles : le bit d’exécution manque (chmod +x), ou le shebang est incorrect. Avec bash script.sh, Bash est appelé directement et le shebang est ignoré, ce qui masque le problème.
Q : Puis-je écrire mes scripts sous Windows ?
R : Oui, via WSL2 (un vrai Linux dans Windows) ou Git Bash. Attention aux fins de ligne : un éditeur Windows peut enregistrer des retours chariot CRLF qui font échouer le script avec un message « No such file or directory » trompeur. dos2unix corrige ça.
📚 Ressources et références
- GNU Bash Reference Manual — la documentation officielle, source de vérité.
- Page du projet GNU Bash — versions et annonces (5.3 depuis juillet 2025).
- Ligne de commande Linux : tutoriel pas-à-pas — pour consolider les bases du terminal.
Mots-clés : premier script bash, shebang, chmod +x, variables bash, substitution de commande, script shell débutant, info-systeme.sh.