Tilde dans PATH : comprendre et corriger l’erreur

Ce que fait réellement la tilde dans une affectation

Dans les shells Unix, ~ peut être développée en chemin vers le répertoire personnel de l'utilisateur. Mais ce n'est pas automatique dans tous les contextes. Ce n'est pas une « substitution universelle » qui remplace chaque tilde à chaque endroit.

Bash, par exemple, développe une tilde en début de mot non cité. Il gère aussi certains cas dans les affectations de variables : une tilde non citée au début d'une affectation, ou juste après un deux-points, peut être développée. Le deux-points compte, parce qu'il sépare les entrées de PATH.

Comparez ces deux écritures :

export PATH="$PATH:~/.local/bin"
export PATH="$PATH:$HOME/.local/bin"

Dans la première ligne, les guillemets englobent l'expression entière. La tilde fait donc partie d'une chaîne citée ; Bash ne la développe pas en chemin vers le dossier personnel.

Dans la seconde, $HOME est explicitement demandé. Les guillemets protègent l'évaluation (et évitent que des caractères spéciaux cassent l'affectation), tout en laissant la variable s'étendre.

En bref : les guillemets doubles ne « désactivent pas tout ». $HOME reste interprété. La tilde, elle, suit des règles plus strictes - et c'est là que ça piège facilement.

export PATH=$PATH:~/.local/bin

Comment une entrée incorrecte de PATH est interprétée

PATH est une liste de répertoires séparés par des deux-points. Quand vous lancez une commande sans chemin complet, le shell parcourt ces répertoires dans l'ordre et cherche un exécutable portant le bon nom.

~/.local/bin n'est pas « reconverti » automatiquement au moment où le shell lit PATH. Si la tilde n'a pas été développée au moment de l'affectation, l'entrée reste littérale.

Comme elle ne commence pas par /, elle devient relative au répertoire de travail courant. Le shell peut donc chercher un fichier dans un chemin du type ./~/.local/bin.

Le résultat peut être trompeur : ce n'est pas forcément ignoré et ça ne déclenche pas forcément une erreur visible. Si un dossier nommé ~ existe (par hasard) dans le répertoire courant et contient l'exécutable attendu, la commande « marche ». Puis elle « ne marche plus » plus tard - selon l'endroit d'où vous lancez.

mkdir -p ./~/.local/bin
printf '#include <stdio.h>\nint main() { puts("bonjour"); }\n' > a.c
gcc a.c -o ./~/.local/bin/demo
PATH="~/.local/bin" demo

Comment vérifier et corriger votre configuration

Commencez par inspecter la valeur réelle de PATH, pas seulement « ce que vous croyez avoir écrit ».

Pour repérer rapidement une tilde dans PATH :

echo "$PATH" | grep -- '~'

Pour afficher chaque entrée séparément (pratique quand la variable est longue) :

printf '%s' "$PATH" | tr ':' '\n' | grep -- '~'

Si vous voyez une ligne avec ~, gardez en tête : ce n'est pas automatiquement une catastrophe dans tous les cas. Mais une entrée du type ~/.local/bin est un bon indice qu'une expansion n'a pas eu lieu comme prévu.

Vous pouvez aussi afficher toutes les entrées sans filtrage :

printf '%s' "$PATH" | tr ':' '\n'

Ensuite, cherchez la partie ajoutée par votre configuration. Selon le shell, il s'agit souvent de ~/.bashrc, ~/.zshrc ou ~/.profile. Quel fichier est réellement lu dépend du shell, de la façon dont la session a été démarrée, et de la machine.

Si vous ne savez pas par où passer, vérifiez le shell en cours avec ps -p $$ -o comm= et regardez les fichiers de configuration pertinents.

export PATH="$PATH:$HOME/.local/bin"

source ~/.bashrc

source ~/.zshrc

Ce que cette erreur implique pour la sécurité et les outils

PATH décide quels exécutables sont trouvés quand vous lancez une commande sans chemin complet. Et comme l'ordre compte, deux dossiers contenant des exécutables du même nom peuvent donner des résultats différents : le premier rencontré gagne.

C'est précisément pour ça que des outils d'audit et de sandboxing s'intéressent aux entrées accessibles en écriture. Si votre PATH contient un chemin ambigu ou relatif, vous pouvez accidentellement autoriser l'exécution de quelque chose que vous n'avez pas prévu.

Une entrée correctement développée en ~/.local/bin pointe vers un emplacement précis. Une entrée littérale relative (comme ~/.local/bin qui n'a pas été développée) dépend du répertoire courant et peut pointer vers un endroit inattendu. Si, dans ce contexte, un exécutable du même nom existe à la première position du PATH, le shell peut le lancer.

Ce n'est pas automatiquement la preuve d'une compromission. Mais c'est une configuration qui mérite d'être clarifiée, parce qu'elle ouvre la porte à des comportements « surprenants ».

C'est aussi dans ce contexte qu'un outil comme nono peut signaler des éléments de PATH accessibles en écriture. Une alerte mentionnant ~/.local/bin/ vaut la peine, mais la forme affichée ne suffit pas : il faut vérifier la valeur effective de PATH, l'ordre, et ce que l'outil considère comme modifiable.

Le bon réflexe n'est pas de désactiver l'alerte sur-le-champ, ni de conclure trop vite à une faille grave. Vérifiez plutôt : résolution du chemin, permissions, et où ça se place dans l'ordre du PATH. Un bon avertissement précise généralement si l'entrée est relative, vers quel chemin elle se résout, et pourquoi elle est considérée modifiable. Sinon, l'alerte donne une piste, pas un verdict.

Conclusion

Une tilde dans PATH n'est pas forcément développée : dans une affectation citée, elle peut rester un simple caractère. Du coup, l'entrée devient relative au répertoire courant et votre comportement peut changer selon l'endroit d'où vous lancez les commandes.

La correction est directe : écrivez export PATH="$PATH:$HOME/.local/bin", rechargez le bon fichier, puis vérifiez le contenu de PATH ligne par ligne. Si un outil de sandboxing vous alerte sur un chemin « accessible en écriture », traitez-le comme un point de départ : vérifiez comment le chemin se résout et quelles permissions s'y appliquent.

Prenez quelques minutes pour relire vos fichiers .bashrc, .zshrc et .profile. Ce petit détail évite un bug discret, vraiment pénible à diagnostiquer, et inutile à conserver.