Votre premier script Bash : créer et lancer pas à pas

Vous n'avez jamais écrit de script ? Cette page est le chemin le plus court vers un premier script Bash qui marche : un fichier, une ligne shebang, le droit d'exécution, et c'est lancé. En quelques minutes, vous saurez créer, rendre exécutable et lancer un script, avec variables et arguments, sans aucun prérequis en programmation. Pour les conditions, les boucles et les fonctions, le guide complet du script shell Bash prend le relais.

Ce que vous allez apprendre

• Créer un script avec le shebang #!/bin/bash
• Le rendre exécutable avec chmod +x
• Utiliser des variables pour stocker des valeurs
• Lire une entrée utilisateur avec read
• Récupérer des arguments passés au script
• Quitter proprement avec un code de sortie

Créer un script minimal

Un script n'est rien d'autre qu'un fichier texte contenant les commandes que vous auriez tapées à la main. Les 5 étapes ci-dessous en produisent un complet, et deux d'entre elles surprennent souvent : le fichier doit recevoir le droit d'exécution, et son lancement demande un ./ devant son nom.

1. Créez un fichier nommé bonjour.sh :

   nano bonjour.sh

2. Écrivez ce contenu :

   #!/bin/bash
   echo "Bonjour, bienvenue sur $(hostname) !"

3. Enregistrez et quittez (Ctrl+O, Entrée, Ctrl+X).

4. Rendez le fichier exécutable :

   chmod +x bonjour.sh

5. Lancez le script :

   ./bonjour.sh

Résultat

Bonjour, bienvenue sur serveur01 !

Le shebang : #!/bin/bash

La première ligne d'un script doit être le shebang :

#!/bin/bash

Elle indique au système quel interpréteur utiliser pour exécuter le fichier. Sans cette ligne, le système ne sait pas qu'il s'agit d'un script Bash.

Toujours en première ligne

Le shebang doit être la toute première ligne du fichier, sans espace ni ligne vide avant.

Rendre exécutable et lancer

Par défaut, un nouveau fichier n'est pas exécutable. Deux étapes sont nécessaires :

chmod +x mon-script.sh
./mon-script.sh

Le ./ indique au shell de chercher le fichier dans le répertoire courant.

Il existe une alternative, utile quand vous n'avez pas le droit de modifier les permissions du fichier : appeler Bash directement sur le script.

bash mon-script.sh

L'interpréteur est alors choisi par la commande, et non par le shebang, qui est simplement ignoré. C'est pratique pour un essai rapide, mais la méthode standard reste chmod +x suivie de ./mon-script.sh : elle rend le script utilisable comme n'importe quelle commande.

Les variables

Une variable stocke une valeur pour la réutiliser :

#!/bin/bash
NOM="Alice"
MACHINE=$(hostname)
echo "Bonjour $NOM, vous êtes sur $MACHINE"

Règles :

• Pas d'espaces autour du =
• Pour lire la valeur : $NOM
• $(commande) capture le résultat d'une commande

Bonnes pratiques de nommage

Ces conventions ne sont pas imposées par Bash, qui accepterait bien pire : elles existent pour que le script reste relisible des mois plus tard, par vous ou par quelqu'un d'autre. La plus rentable est la deuxième, un nom descriptif, parce qu'elle supprime le besoin de remonter dans le code pour savoir ce que contient une variable.

Convention	Exemple
Majuscules pour les variables globales	REPERTOIRE, NOM_FICHIER
Nom descriptif	FICHIER_LOG plutôt que F
Pas de caractères spéciaux	Uniquement lettres, chiffres, _

Glissez pour voir

Lire une entrée utilisateur

La commande read met le script en pause et attend que l'utilisateur tape quelque chose :

#!/bin/bash
echo "Quel est votre prénom ?"
read PRENOM
echo "Bonjour $PRENOM !"

Pour afficher le message et la saisie sur la même ligne :

read -p "Votre prénom : " PRENOM
echo "Bonjour $PRENOM !"

Les arguments

Un script peut recevoir des valeurs au moment du lancement :

./saluer.sh Alice Bob

Ces valeurs sont accessibles via des variables spéciales :

Variable	Contenu
$1	Premier argument (Alice)
$2	Deuxième argument (Bob)
$#	Nombre d'arguments (2)
$@	Tous les arguments (Alice Bob)
$0	Nom du script (./saluer.sh)

Glissez pour voir

Exemple complet :

#!/bin/bash
echo "Script : $0"
echo "Argument 1 : $1"
echo "Argument 2 : $2"
echo "Nombre d'arguments : $#"

Vérifier qu'un argument est fourni

Un script robuste vérifie que les arguments nécessaires sont présents :

#!/bin/bash
if [ -z "$1" ]; then
  echo "Usage : $0 <nom>"
  exit 1
fi
echo "Bonjour $1 !"

-z "$1" teste si le premier argument est vide. Si c'est le cas, le script affiche un message d'aide et s'arrête.

Les codes de sortie

Chaque commande (et chaque script) retourne un code de sortie :

Code	Signification
0	Succès
1	Erreur générale
2	Mauvaise utilisation (arguments incorrects)

Glissez pour voir

Pour terminer un script avec un code précis :

exit 0   # tout s'est bien passé
exit 1   # une erreur s'est produite

Pour vérifier le code de sortie de la dernière commande :

echo $?

Les commentaires

Un commentaire commence par #. Le shell ignore tout ce qui suit sur la ligne :

#!/bin/bash
# Ce script affiche un message de bienvenue
NOM="Alice"    # Variable contenant le prénom
echo "Bonjour $NOM"

Commentez votre code pour expliquer pourquoi vous faites quelque chose, pas quoi (le code le montre déjà).

Exemple complet : rapport système

Voici un script concret qui rassemble des informations sur le système :

#!/bin/bash
# rapport-systeme.sh : Affiche un résumé de l'état du système

echo "=== Rapport système ==="
echo "Date    : $(date)"
echo "Machine : $(hostname)"
echo "Utilisateur : $USER"
echo "Répertoire  : $PWD"
echo ""
echo "Espace disque :"
df -h /
echo ""
echo "Mémoire :"
free -h
echo "=== Fin du rapport ==="

chmod +x rapport-systeme.sh
./rapport-systeme.sh

Ce script ne fait qu'enchaîner des commandes que vous connaissez déjà. C'est le principe d'un script : automatiser une séquence de tâches répétitives.

Dépannage

Les échecs d'un premier script se ressemblent tous : le fichier est là, son contenu est correct, et rien ne s'exécute. Trois causes couvrent l'essentiel, un droit d'exécution absent, un ./ oublié devant le nom, et un fichier enregistré avec des fins de ligne Windows. Aucune ne concerne le code lui-même.

Symptôme	Cause probable	Solution
Permission denied	Script non exécutable	chmod +x mon-script.sh
command not found en lançant script.sh	./ manquant devant le nom	Lancer avec ./script.sh
cannot execute: required file not found	Shebang incorrect ou caractères Windows (CRLF)	Vérifier #!/bin/bash en première ligne, convertir avec dos2unix
Variable vide dans le script	Mauvais nom ou $ oublié	Vérifier le nom exact et le $ devant
[: -z: unexpected operator	Espaces manquants dans le test [ ]	Écrire [ -z "$1" ] avec des espaces
Script qui ne s'arrête pas	Boucle implicite ou read en attente	Ctrl+C pour interrompre

Glissez pour voir

Le message bad interpreter n'existe plus

Si vous cherchez bad interpreter: No such file or directory, le message qu'affichent encore la plupart des tutoriels, vous ne le trouverez pas. Bash 5.2 a changé de formulation, et c'est désormais le même message pour un shebang erroné et pour un fichier enregistré avec des fins de ligne Windows :

bash: ./mon-script.sh: cannot execute: required file not found

Le code de retour est 127. La cause reste identique : le noyau ne trouve pas l'interpréteur indiqué après le #!. Dans le cas du CRLF, l'interpréteur cherché est littéralement /bin/bash\r, avec un retour chariot invisible à la fin, d'où un fichier « introuvable » alors que /bin/bash existe bel et bien.

file mon-script.sh    # « with CRLF line terminators » trahit le coupable
dos2unix mon-script.sh

Mettre en pratique

Un script ne se comprend qu'en l'écrivant soi-même, puis en le lançant sur de vraies données. Ce lab vous fait produire un rapport.sh qui lit un fichier d'état passé en argument, compte les hôtes UP/DOWN avec une boucle et une condition, puis renvoie un code de sortie non nul dès qu'un hôte est down. Votre script est comparé au comportement attendu.

Lab pratique

Écrire un premier script Bash

$ dsoxlab run l1-bash-script

Environnement : Shell·Durée : ~35 min

Validé : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l1-bash-script
dsoxlab check l1-bash-script

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Un script commence par #!/bin/bash (shebang) qui identifie l'interpréteur.
• chmod +x rend le fichier exécutable, ./script.sh le lance.
• Les variables (NOM="valeur") et arguments ($1, $2) rendent un script flexible.
• read permet de demander une saisie, echo d'afficher un résultat.
• exit 0 signale un succès, exit 1 une erreur, testable avec echo $?.
• Commentez vos scripts pour les rendre compréhensibles.

Pour aller plus loin

• Écrire un script shell Bash : le guide complet : Variables, conditions, boucles, fonctions et débogage.
• Écrire des scripts robustes : set -euo pipefail, shellcheck et bonnes pratiques.

×

📖 Voir la documentation →