PATH sous Linux : ajouter une commande sans casser votre shell

Vous venez d’installer un outil Linux, vous tapez sa commande, et le shell répond command not found. Dans beaucoup de cas, l’outil est bien présent. Il est simplement rangé dans un dossier que votre variable PATH ne parcourt pas.

Je vous conseille de traiter ça proprement. Ajouter un dossier au PATH peut dépanner en trente secondes, mais une mauvaise ligne dans .bashrc, un dossier douteux placé en tête, ou un PATH dupliqué à chaque ouverture de terminal peuvent vite rendre la session pénible.

On va voir comment lire votre PATH, tester un ajout temporaire, le rendre durable avec .bashrc ou .profile, puis vérifier que la bonne commande est appelée.

Commencez par regarder le PATH actuel

Le PATH est une liste de dossiers séparés par des deux-points. Quand vous tapez une commande, le shell cherche dans ces dossiers, dans l’ordre.

echo "$PATH"

La sortie est souvent longue. Pour la lire plus facilement, affichez un dossier par ligne :

OLDIFS=$IFS
IFS=:
for dir in $PATH; do
  echo "$dir"
done
IFS=$OLDIFS

Sur une machine classique, vous allez retrouver des dossiers comme /usr/local/bin, /usr/bin, /bin, parfois $HOME/.local/bin. Si le dossier qui contient votre script n’apparaît pas, le shell ne le trouvera pas sans chemin complet.

Avant de modifier quoi que ce soit, vérifiez aussi où se trouve la commande :

command -v monoutil
type -a monoutil

command -v indique le chemin réellement utilisé. type -a est pratique quand plusieurs commandes portent le même nom. C’est exactement le genre de vérification qui évite de lancer un vieux binaire sans s’en rendre compte.

Ajouter un dossier au PATH seulement pour la session

Pour tester sans rien casser, ajoutez d’abord le dossier uniquement dans le terminal actuel. Par exemple, si vous placez vos petits scripts dans ~/.local/bin :

mkdir -p "$HOME/.local/bin"
export PATH="$HOME/.local/bin:$PATH"

Le dossier est placé au début du PATH. Votre shell le consultera donc avant /usr/bin ou /bin. C’est utile pour tester un script personnel, mais ce n’est pas un détail neutre : si une commande porte le même nom qu’un outil système, c’est votre version qui sera appelée.

Vérifiez tout de suite :

echo "$PATH"
command -v monoutil

Si votre script est dans ce dossier mais ne se lance pas, regardez aussi les droits d’exécution :

ls -l "$HOME/.local/bin/monoutil"
chmod +x "$HOME/.local/bin/monoutil"

Si vous devez revoir les droits sur plusieurs fichiers, l’article sur chmod récursif sous Linux peut vous éviter une commande trop large. Ici, on donne simplement le droit d’exécution au fichier concerné.

Rendre l’ajout durable dans .bashrc

Si le test fonctionne, vous pouvez rendre l’ajout durable. Pour un terminal Bash interactif, le fichier le plus courant est ~/.bashrc.

nano ~/.bashrc

Ajoutez cette logique en bas du fichier :

case ":$PATH:" in
  *":$HOME/.local/bin:"*) ;;
  *) export PATH="$HOME/.local/bin:$PATH" ;;
esac

Cette version évite de réinjecter le même dossier à chaque chargement. C’est plus propre qu’un simple export PATH="$HOME/.local/bin:$PATH" répété dans plusieurs fichiers.

Rechargez ensuite le fichier sans fermer votre session :

source ~/.bashrc

Ouvrez aussi un nouveau terminal pour confirmer que l’ajout revient bien automatiquement :

OLDIFS=$IFS
IFS=:
for dir in $PATH; do
  echo "$dir"
done
IFS=$OLDIFS
command -v monoutil

.bashrc, .profile ou /etc/profile.d : lequel choisir ?

Le bon fichier dépend de votre usage. Sur une station de travail ou un serveur où vous ouvrez surtout des shells interactifs en Bash, ~/.bashrc suffit souvent.

Pour une session de connexion, notamment quand vous voulez que la variable soit disponible plus largement après login, regardez plutôt ~/.profile. Certaines distributions y ajoutent déjà $HOME/bin ou $HOME/.local/bin si le dossier existe.

Pour une configuration système destinée à tous les utilisateurs, évitez d’empiler des modifications dans chaque compte. Utilisez plutôt un fichier dédié dans /etc/profile.d/, avec prudence :

sudo nano /etc/profile.d/outils-locaux.sh

Exemple simple pour un dossier administré :

export PATH="/opt/outils/bin:$PATH"

Je réserve ce type d’ajout aux chemins maîtrisés, avec des droits propres. Si n’importe quel utilisateur peut écrire dans le dossier, il ne doit pas être en tête du PATH global. La documentation Bash liste les variables utilisées par le shell, et la page PATH du manuel Bash rappelle le rôle de cette variable.

Évitez les chemins dangereux en tête du PATH

Le piège classique consiste à ajouter un dossier pratique, mais trop ouvert. Par exemple, mettre . dans le PATH permet de lancer une commande depuis le dossier courant sans écrire ./script. Je vous le déconseille.

Imaginez un dossier de téléchargement qui contient un faux ls, ssh ou sudo. Si le dossier courant passe avant les chemins système, vous pouvez lancer le mauvais programme sans le voir. Sur un serveur, c’est une mauvaise habitude à bannir.

Quelques règles simples :

• ne mettez pas . dans le PATH ;
• évitez les dossiers où d’autres utilisateurs peuvent écrire ;
• placez les scripts personnels dans $HOME/.local/bin plutôt que dans un dossier de téléchargement ;
• vérifiez avec type -a si une commande existe à plusieurs endroits ;
• gardez les chemins système classiques dans le PATH.

La page environ(7) détaille aussi le rôle des variables d’environnement côté Linux. Ce n’est pas une lecture obligatoire pour ajouter un script personnel, mais elle aide à comprendre ce qui est transmis aux processus.

Vérifier que le shell utilise la bonne commande

Après modification, ne vous contentez pas de voir que la commande se lance. Vérifiez son chemin exact :

command -v monoutil
type -a monoutil

Si vous venez de déplacer ou remplacer une commande, Bash peut aussi garder un ancien chemin en cache. Dans ce cas :

hash -r
command -v monoutil

Vous pouvez ensuite lancer une commande de version ou d’aide, si l’outil en propose une :

monoutil --version
monoutil --help

Si vous cherchez le fichier exact avant de décider où le ranger, vous pouvez aussi utiliser find sous Linux. C’est souvent plus propre que de modifier le PATH au hasard pour compenser un fichier mal placé.

Ma méthode propre pour ajouter une commande personnelle

Sur une machine personnelle ou un petit serveur, je fais généralement simple :

• je place mes scripts dans $HOME/.local/bin ;
• je donne le droit d’exécution seulement aux fichiers nécessaires ;
• j’ajoute le dossier dans ~/.bashrc avec un test anti-doublon ;
• je vérifie avec command -v et type -a ;
• je garde les chemins système et les dossiers sensibles sous contrôle.

Si vous administrez plusieurs comptes ou un serveur partagé, soyez plus strict. Un PATH global mal pensé peut produire des comportements difficiles à diagnostiquer, surtout quand un script fonctionne en SSH mais pas dans une session interactive, ou l’inverse. Dans ce cas, documentez le chemin ajouté et testez avec un nouvel utilisateur avant de considérer la modification comme propre.

sudo apt update && sudo apt upgrade