Comment exécuter un fichier .sh sous Linux : Guide complet pour les débutants et les administrateurs système

Les scripts shell sont l’épine dorsale de l’automatisation Linux. Que vous déployiez une application web, planifiiez des sauvegardes ou configuriez un serveur fraîchement provisionné, les fichiers .sh vous permettent de regrouper des séquences de commandes complexes dans un seul exécutable répétable. Ce guide vous présente toutes les méthodes pour exécuter des scripts shell sous Linux — de l’exécution basique aux processus en arrière-plan et à la planification cron — avec les meilleures pratiques qui fonctionnent dans les environnements de production.

Qu’est-ce qu’un fichier .sh sous Linux ?

Un fichier .sh est un script en texte brut écrit en langage shell (généralement Bash ou POSIX sh) que le shell Linux interprète et exécute ligne par ligne. Les scripts shell sont utilisés pour :

• Automatiser les tâches répétitives d’administration système
• Déployer et configurer des applications
• Gérer les utilisateurs, les permissions et les systèmes de fichiers
• Planifier les tâches de maintenance comme les sauvegardes et la rotation des journaux
• Amorcer les nouveaux serveurs après le provisionnement

Si vous gérez un environnement VPS Hosting ou un Serveur Dédié, les scripts shell sont une compétence indispensable qui vous fera gagner des heures de travail manuel chaque semaine.

Prérequis

Avant d’exécuter un fichier .sh, assurez-vous que vous disposez de :

• L’accès à un terminal Linux (local ou via SSH)
• Un compte utilisateur avec les permissions appropriées
• Le fichier script déjà sur le système (créé localement ou transféré via SCP/SFTP)

Méthode 1 : Rendre le fichier exécutable avec chmod

Par défaut, les fichiers .sh nouvellement créés ou téléchargés n’ont pas de permissions d’exécution. Avant d’exécuter le script en tant que programme, vous devez explicitement accorder les droits d’exécution à l’aide de la commande chmod.

chmod +x script.sh

Pour vérifier que les permissions ont été appliquées correctement :

ls -l script.sh

Vous devriez voir une sortie similaire à :

-rwxr-xr-x 1 user user 1024 Jun 10 14:32 script.sh

Les drapeaux x confirment que le fichier est maintenant exécutable par le propriétaire, le groupe et les autres.

> Conseil de sécurité : Si vous souhaitez restreindre l’exécution au seul propriétaire du fichier, utilisez chmod 700 script.sh au lieu de chmod +x.

Méthode 2 : Exécuter le script avec un chemin relatif ou absolu

Une fois le fichier exécutable, vous pouvez l’exécuter directement à partir du terminal.

Utiliser un chemin relatif (répertoire courant)

Si le script se trouve dans votre répertoire de travail actuel, préfixez-le avec ./ :

./script.sh

Le ./ indique au shell de chercher dans le répertoire courant plutôt que de rechercher dans le $PATH système.

Utiliser un chemin absolu

Si le script est stocké dans un autre emplacement, fournissez son chemin complet :

/home/user/scripts/script.sh

ou

/usr/local/bin/script.sh

L’utilisation de chemins absolus est particulièrement importante lors de l’exécution de scripts à partir de tâches cron ou d’autres contextes automatisés où le répertoire de travail peut différer.

Méthode 3 : Exécuter le script avec bash ou sh (aucune permission d’exécution requise)

Vous pouvez invoquer un script shell en appelant explicitement l’interpréteur, même si le fichier n’a pas de permissions d’exécution. Ceci est particulièrement utile pour tester rapidement un script avant de le rendre définitivement exécutable.

bash script.sh

ou, pour les scripts conformes à POSIX :

sh script.sh

Différence entre bash et sh

Si votre script utilise une syntaxe spécifique à Bash comme les tableaux, les conditionnelles [[ ]] ou la substitution de processus, utilisez toujours bash plutôt que sh.

Méthode 4 : Exécuter le script en tant que superutilisateur (sudo)

Certains scripts nécessitent des privilèges au niveau root pour modifier les fichiers système, gérer les services, installer des packages ou modifier les configurations réseau. Utilisez sudo pour élever les permissions :

sudo ./script.sh

ou passez le script directement à bash avec des droits élevés :

sudo bash script.sh

Considérations importantes en matière de sécurité

• N’exécutez jamais un script en tant que root sans le lire d’abord. Un script malveillant ou mal écrit avec accès sudo peut causer des dommages irréversibles au système.
• Préférez exécuter les scripts avec les permissions minimales requises.
• Si un script ne doit écrire que dans un répertoire spécifique, envisagez d’ajuster les permissions du répertoire plutôt que d’exécuter l’ensemble du script en tant que root.

Méthode 5 : Exécuter le script en arrière-plan

Par défaut, l’exécution d’un script dans le terminal bloque votre session jusqu’à ce que le script se termine. Pour les tâches longues — comme les transferts de fichiers volumineux, les migrations de bases de données ou les constructions de serveurs — vous voudrez envoyer le processus en arrière-plan.

Utiliser l’opérateur &

./script.sh &

Le symbole & crée un fork du processus en arrière-plan et retourne immédiatement le contrôle à votre terminal. Le shell affiche le PID (ID de processus) de la tâche en arrière-plan, que vous pouvez utiliser pour la surveiller ou l’arrêter ultérieurement.

Maintenir le script en exécution après la déconnexion avec nohup

Si vous vous déconnectez de SSH, les tâches en arrière-plan lancées avec & se termineront généralement. Utilisez nohup pour éviter cela :

nohup ./script.sh &

La sortie est redirigée vers nohup.out par défaut. Pour spécifier un fichier journal personnalisé :

nohup ./script.sh > /var/log/myscript.log 2>&1 &

Surveiller les tâches en arrière-plan

jobs          # List background jobs in the current session
ps aux | grep script.sh   # Find the process by name
kill PID      # Terminate a specific background process

Méthode 6 : Planifier l’exécution du script avec Cron

Pour les tâches récurrentes — sauvegardes nocturnes, nettoyages hebdomadaires, vérifications de santé horaires — le planificateur cron intégré de Linux est la solution standard.

Ouvrir l’éditeur Crontab

crontab -e

Syntaxe Cron

* * * * * /path/to/script.sh
│ │ │ │ │
│ │ │ │ └── Day of week (0–7, Sunday = 0 or 7)
│ │ │ └──── Month (1–12)
│ │ └────── Day of month (1–31)
│ └──────── Hour (0–23)
└────────── Minute (0–59)

Exemples pratiques de Cron

Exemple : Sauvegarde quotidienne automatisée

0 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

Ceci exécute backup.sh tous les jours à 2h00 et ajoute la sortie standard et les erreurs à un fichier journal pour l’audit.

> Conseil professionnel : Utilisez toujours des chemins absolus dans les entrées cron. Cron s’exécute avec un environnement minimal et peut ne pas avoir accès au même $PATH que votre shell interactif.

Méthode 7 : Sourcer un script (exécuter dans le contexte du shell actuel)

Il y a une autre méthode d’exécution qui vaut la peine d’être connue : sourcer un script. Contrairement aux méthodes ci-dessus, sourcer exécute le script dans la session shell actuelle plutôt que de créer un sous-shell. Cela signifie que toutes les variables ou fonctions définies dans le script persistent dans votre environnement actuel.

source script.sh

ou de manière équivalente :

. script.sh

Ceci est couramment utilisé pour charger les variables d’environnement, activer les environnements virtuels ou appliquer les modifications de configuration à la session actuelle.

Dépannage des erreurs courantes

Meilleures pratiques pour écrire et exécuter des scripts shell

Suivre ces pratiques rendra vos scripts plus sûrs, plus faciles à maintenir et plus faciles à déboguer — en particulier dans les environnements serveur.

1. Commencez toujours par une ligne Shebang

La première ligne de chaque script doit déclarer l’interpréteur :

#!/bin/bash

ou pour une portabilité maximale :

#!/usr/bin/env bash

2. Activer le mode strict

Ajoutez ceci près du haut de chaque script de production :

set -euo pipefail

• -e — Quitter immédiatement si une commande échoue
• -u — Traiter les variables non définies comme des erreurs
• -o pipefail — Capturer les défaillances dans les commandes en pipeline

3. Lire le script avant de l’exécuter

N’exécutez jamais un fichier .sh provenant d’une source externe ou non fiable sans en examiner d’abord le contenu :

cat script.sh

ou ouvrez-le dans un éditeur de texte. Ceci est particulièrement critique lors de l’exécution avec sudo.

4. Utiliser les commentaires généreusement

#!/bin/bash
# backup.sh — Daily backup script for /var/www
# Author: sysadmin@example.com
# Last updated: 2024-06-10

# Define source and destination directories
SOURCE="/var/www"
DEST="/mnt/backup"

5. Organiser les scripts dans des répertoires dédiés

6. Enregistrer la sortie du script

Redirigez toujours la sortie vers un fichier journal pour les scripts s’exécutant sans surveillance :

./script.sh >> /var/log/script.log 2>&1

7. Tester les scripts dans un environnement sûr d’abord

Avant de déployer un script sur un serveur de production, testez-le sur un environnement de staging ou une instance VPS jetable où les erreurs ne causeront pas de temps d’arrêt.

Exécuter des scripts shell sur un serveur Linux : considérations pratiques

Lors de l’exécution de scripts sur un serveur Linux distant — qu’il s’agisse d’un environnement partagé ou d’une machine dédiée — quelques facteurs supplémentaires entrent en jeu :

• Accès SSH : La plupart des scripts côté serveur s’ex