Linux sans magie #7 — Exécutable ou simple fichier : pourquoi un script ne se lance pas toujours
Comprendre pourquoi un script Linux peut être lisible mais refuser de s’exécuter, avec chmod +x, ./script.sh et un lab simple autour du droit d’exécution.
Vous venez de comprendre les propriétaires, les groupes et les permissions Linux.
Il est maintenant temps de rencontrer un comportement qui surprend beaucoup de débutants.
Vous créez un script.
Vous pouvez le lire.
Son contenu semble parfaitement correct.
Puis vous tapez :
./bonjour.sh
Et Linux vous répond :
Permission denied
Le premier réflexe peut être de penser que le script est cassé.
En réalité, Linux vous dit souvent quelque chose de beaucoup plus simple : ce fichier n’a pas le droit d’être exécuté de cette manière.
Aujourd’hui, nous allons comprendre ce fameux x que nous avons volontairement laissé un peu de côté dans les articles précédents.
Objectif
À la fin de ce lab, vous saurez distinguer un simple fichier texte d’un fichier que Linux autorise à exécuter.
Vous comprendrez la différence entre :
bash bonjour.sh
et :
./bonjour.sh
Vous saurez observer le droit x, provoquer volontairement un refus d’exécution, corriger le problème avec :
chmod u+x bonjour.sh
puis vérifier immédiatement le résultat.
Surtout, vous comprendrez pourquoi cette commande fonctionne au lieu de simplement mémoriser chmod +x.
Lab — Créer notre premier petit script
Revenez dans votre répertoire personnel :
cd
Créez un environnement de test :
mkdir linux-sans-magie-lab
cd linux-sans-magie-lab
Vérifiez où vous êtes :
pwd
Créons maintenant un fichier appelé bonjour.sh :
cat > bonjour.sh <<'EOF'
#!/bin/bash
echo "Bonjour depuis Linux sans magie"
EOF
Affichez son contenu :
cat bonjour.sh
Vous devez voir :
#!/bin/bash
echo "Bonjour depuis Linux sans magie"
Pour l’instant, ce fichier n’a rien de mystérieux.
C’est simplement un fichier texte contenant deux lignes.
Observer avant d’exécuter
Regardez ses permissions :
ls -l bonjour.sh
Selon votre configuration, vous pourriez obtenir quelque chose ressemblant à :
-rw-r--r-- 1 alex alex 58 Sep 8 08:00 bonjour.sh
Concentrons-nous sur :
-rw-r--r--
Le propriétaire dispose de :
rw-
Il peut donc lire et écrire.
Mais il manque quelque chose :
x
Sur un fichier ordinaire, x correspond au droit d’exécution.
Notre fichier est donc parfaitement lisible, mais il n’est pas actuellement marqué comme exécutable pour son propriétaire.
Première surprise : Bash peut quand même le lire
Essayez :
bash bonjour.sh
Vous devriez obtenir :
Bonjour depuis Linux sans magie
Le script fonctionne.
Pourtant, nous venons de constater qu’il n’est pas exécutable.
Contradiction ?
Non.
Avec :
bash bonjour.sh
vous n’avez pas demandé à Linux d’exécuter directement bonjour.sh.
Vous avez lancé Bash, qui est lui-même un programme exécutable, puis vous lui avez demandé de lire le contenu de bonjour.sh.
Autrement dit :
bash → lit bonjour.sh → interprète ses commandes
C’est une distinction fondamentale.
Essayons maintenant l’exécution directe
Tapez :
./bonjour.sh
Cette fois, vous devriez normalement obtenir un message ressemblant à :
bash: ./bonjour.sh: Permission denied
Le texte exact dépend du shell et de votre environnement.
Mais le problème est clair.
Nous essayons cette fois d’exécuter directement le fichier.
Or ses permissions ne comportent pas le droit x pour notre utilisateur.
Sous Linux, une tentative d’exécution peut être refusée lorsque la permission d’exécution manque.
Nous venons donc de provoquer volontairement notre erreur.
Et surtout : nous savons déjà comment la diagnostiquer.
Observer → agir → vérifier
Avant de modifier quoi que ce soit :
ls -l bonjour.sh
Nous voyons par exemple :
-rw-r--r--
Quel droit manque au propriétaire pour permettre l’exécution directe ?
Le droit x.
Nous allons donc ajouter uniquement ce droit :
chmod u+x bonjour.sh
Relisez cette commande comme une phrase.
u : propriétaire.
+ : ajouter.
x : droit d’exécution.
Donc :
ajouter au propriétaire le droit d’exécuter ce fichier.
Vérifier immédiatement
Tapez :
ls -l bonjour.sh
Vous devriez maintenant voir quelque chose ressemblant à :
-rwxr--r--
Regardez le premier bloc :
rwx
Le propriétaire peut désormais lire, écrire et exécuter.
Essayez à nouveau :
./bonjour.sh
Résultat attendu :
Bonjour depuis Linux sans magie
Cette fois, l’exécution directe fonctionne.
Que signifie exactement ./ ?
Il reste un détail important.
Pourquoi écrivons-nous :
./bonjour.sh
et pas simplement :
bonjour.sh
Le . représente le répertoire courant.
Donc :
./bonjour.sh
signifie littéralement : exécuter le fichier bonjour.sh qui se trouve dans le répertoire où je suis actuellement.
C’est aussi une bonne occasion de réutiliser deux commandes déjà connues :
pwd
ls
pwd vous dit où vous êtes.
ls vous montre ce qui s’y trouve.
Puis ./bonjour.sh désigne explicitement le fichier présent ici.
Nous verrons plus tard comment Linux recherche les commandes dans des répertoires définis par la variable PATH.
Pour aujourd’hui, retenez simplement que ./ indique explicitement le répertoire courant.
Et la première ligne #!/bin/bash ?
Reprenons notre script :
#!/bin/bash
echo "Bonjour depuis Linux sans magie"
La première ligne :
#!/bin/bash
s’appelle couramment le shebang.
Elle commence par :
#!
et indique ici que le script doit être interprété avec :
/bin/bash
Lorsqu’un script est exécuté directement sous Linux, cette première ligne indique l’interpréteur à utiliser.
Cela explique pourquoi notre fichier contient à la fois :
#!/bin/bash
et des commandes Bash.
Un fichier .sh n’est pas automatiquement exécutable
Voici un piège très fréquent.
Le nom :
bonjour.sh
ne donne aucun droit particulier au fichier.
L’extension .sh est utile pour nous, humains, parce qu’elle suggère qu’il s’agit d’un script shell.
Mais elle ne remplace pas les permissions.
Vous pouvez avoir :
-rw-r--r-- bonjour.sh
Le fichier ressemble à un script, mais n’est pas directement exécutable.
Vous pouvez aussi avoir :
-rwxr-xr-x outil
sans aucune extension.
Ce fichier peut parfaitement être exécutable.
Sous Linux, le droit d’exécution est porté par les permissions du fichier, pas par l’extension de son nom.
Provoquer à nouveau l’erreur
Nous allons volontairement revenir en arrière.
Retirez le droit d’exécution :
chmod u-x bonjour.sh
Vérifiez :
ls -l bonjour.sh
Vous devriez retrouver quelque chose ressemblant à :
-rw-r--r--
Essayez :
./bonjour.sh
L’exécution directe doit de nouveau être refusée dans un environnement Linux classique où aucune autre permission ne vous accorde l’exécution.
Puis testez :
bash bonjour.sh
Le script peut toujours fonctionner de cette façon parce que Bash lit le fichier comme entrée.
Nous venons de rendre visible la différence entre les deux mécanismes.
Diagnostic : un script refuse de démarrer
Imaginons demain que vous rencontriez :
Permission denied
en lançant :
./outil.sh
Ne tapez pas immédiatement :
chmod 777 outil.sh
Commencez par observer.
whoami
ls -l outil.sh
pwd
Posez-vous ensuite ces questions :
Qui suis-je ?
Qui possède le fichier ?
Quels droits possède le propriétaire ?
Le droit x est-il présent pour la catégorie d’utilisateur qui me concerne ?
Suis-je en train d’exécuter directement le fichier ou de demander à un interpréteur de le lire ?
Cette méthode vaut beaucoup plus qu’une commande copiée depuis Internet.
Attention : x ne garantit pas que le programme fonctionnera
Ajouter x signifie que les permissions classiques autorisent l’exécution pour la catégorie concernée.
Cela ne signifie pas pour autant que tout fichier deviendra un programme valide.
Imaginez un fichier contenant :
Bonjour
Puis :
chmod u+x fichier
Le simple fait d’ajouter x ne transforme pas le mot Bonjour en programme.
Un script doit toujours contenir quelque chose qu’un interpréteur peut traiter correctement.
Un programme binaire doit lui aussi avoir un format reconnu.
De plus, Linux peut refuser l’exécution pour d’autres raisons, par exemple lorsqu’un système de fichiers est monté avec l’option noexec.
Nous ne traiterons pas ces cas avancés aujourd’hui.
Le but est d’apprendre à ne pas conclure trop vite : « il manque x, donc chmod +x résout forcément tout ».
Petit défi
Créez un deuxième script :
cat > diagnostic.sh <<'EOF'
#!/bin/bash
echo "Utilisateur : $(whoami)"
echo "Répertoire : $(pwd)"
EOF
Ne lui ajoutez pas immédiatement le droit d’exécution.
Commencez par :
ls -l diagnostic.sh
Puis tentez :
./diagnostic.sh
Analysez le résultat.
Ensuite seulement :
chmod u+x diagnostic.sh
Vérifiez :
ls -l diagnostic.sh
Et relancez :
./diagnostic.sh
Vous devriez obtenir quelque chose ressemblant à :
Utilisateur : alex
Répertoire : /home/alex/linux-sans-magie-lab
Votre objectif n’est pas seulement de réussir à lancer le script.
Vous devez pouvoir expliquer pourquoi il échouait avant et pourquoi il fonctionne maintenant.
Sécurité
Le droit d’exécution mérite la même prudence que les autres permissions.
Ne rendez pas automatiquement exécutable tout fichier téléchargé ou reçu d’une source inconnue.
Un script est du code.
S’il contient des commandes dangereuses, le fait qu’il soit petit ou facile à lire ne le rend pas automatiquement sûr.
Avant d’exécuter un script inconnu, commencez au minimum par examiner son contenu avec un outil de lecture adapté.
Dans notre lab, nous avons créé nous-mêmes tous les fichiers et nous savons exactement ce qu’ils contiennent.
Aller plus loin
Vous avez utilisé :
chmod u+x bonjour.sh
Nous aurions aussi pu rencontrer :
chmod +x bonjour.sh
Mais il existe une différence pédagogique importante.
Avec :
chmod u+x bonjour.sh
nous indiquons explicitement à quelle catégorie nous ajoutons le droit.
Cette précision est utile à ce stade de la série.
Dans le prochain article consacré plus largement à chmod, nous apprendrons à lire et construire les permissions symboliques et numériques sans transformer 644, 755 ou 750 en nombres magiques.
Nettoyage / rollback
Assurez-vous d’abord d’être toujours dans le lab :
pwd
Revenez ensuite dans votre répertoire personnel :
cd
Vérifiez :
pwd
Puis supprimez uniquement notre environnement de test :
rm -r linux-sans-magie-lab
Vérifiez :
ls
Le répertoire doit avoir disparu.
Ce qu’il faut retenir
Un fichier texte et un fichier exécutable ne se distinguent pas simplement par leur nom ou leur extension.
Pour exécuter directement :
./bonjour.sh
le droit x doit notamment être accordé à la catégorie d’utilisateur appropriée.
Avec :
bash bonjour.sh
vous demandez en revanche à Bash de lire et interpréter le fichier.
Et avec :
#!/bin/bash
le script indique quel interpréteur utiliser lorsqu’il est lancé directement sous Linux.
La méthode reste exactement celle de toute la série : observer → comprendre → agir → vérifier.
Références officielles
- GNU Coreutils — File permissions — GNU
- GNU Coreutils — Setting Permissions — GNU
- Linux man-pages — execve(2) — Linux man-pages
Conclusion
Vous savez maintenant pourquoi un fichier peut être parfaitement lisible et pourtant refuser :
./script.sh
Vous avez vu que x n’est pas un symbole abstrait : il autorise l’exécution du fichier pour une catégorie d’utilisateurs.
Vous avez également appris à distinguer l’exécution directe d’un script de son interprétation explicite avec Bash.
Le prochain article de la séquence sera :
Linux sans magie #8 — chmod sans peur : symbolique, octal et erreurs classiques