
Erreur commune : problèmes de PATH après l'installation
Vous rencontrez une erreur "command not found" après avoir installé Ruby avec rbenv ? Apprenez à diagnostiquer et corriger les problèmes de PATH, une erreur de configuration fréquente. Ce guide vous rendra autonome pour assurer un environnement stable.
Quel est le symptôme et pourquoi ne faut-il pas paniquer ?
Le scénario est classique : vous venez de terminer l'installation, vous tapez fièrement ruby -v dans votre terminal, et au lieu de la version attendue, vous recevez un message frustrant comme zsh: command not found: ruby ou bash: ruby: command not found. Votre premier réflexe pourrait être de penser que toute l'installation a échoué. Rassurez-vous, ce n'est presque jamais le cas.
Cette erreur ne signifie pas que Ruby n'est pas installé. Elle signifie simplement que votre shell (l'interpréteur de commandes de votre terminal) ne sait pas où trouver l'exécutable ruby que rbenv a installé pour vous. C'est un problème d'adressage, pas d'existence. Nous allons apprendre à donner la bonne adresse à votre shell.
Comprendre le concept de PATH et le rôle de `rbenv init`
Pour comprendre la solution, il faut comprendre le mécanisme du PATH. Le PATH est une variable d'environnement, une sorte de "carnet d'adresses" que votre shell consulte chaque fois que vous tapez une commande. Il contient une liste de répertoires, séparés par des deux-points. Quand vous tapez ruby, le shell parcourt chaque répertoire de cette liste, dans l'ordre, jusqu'à ce qu'il trouve un fichier exécutable nommé ruby. S'il arrive au bout de la liste sans le trouver, il affiche l'erreur "command not found".
C'est ici que la ligne eval "$(rbenv init - ...)" que vous avez ajoutée à votre fichier de configuration (~/.zshrc ou ~/.bash_profile) devient capitale. Son unique rôle est de dire à votre shell : "Avant de chercher dans ton carnet d'adresses habituel, regarde d'abord dans le répertoire spécial de rbenv (appelé 'shims')." Si cette ligne est absente, mal placée ou si le fichier n'est pas lu au démarrage, votre shell ne regardera jamais au bon endroit.
Comment diagnostiquer précisément l'origine du problème ?
Le dépannage doit être méthodique. La première chose à faire est de vérifier si la configuration de rbenv est bien chargée. Pour cela, affichez le contenu de votre PATH actuel avec la commande suivante :
echo $PATHAnalysez la sortie. Si rbenv est correctement configuré, vous devriez voir un chemin contenant .rbenv/shims tout au début de la ligne. Par exemple : /Users/votre_nom/.rbenv/shims:/usr/local/bin:/usr/bin:.... Si ce chemin est absent ou s'il n'est pas au début, vous avez trouvé la cause du problème.
Ensuite, vérifiez que la ligne d'initialisation est bien présente dans le bon fichier de configuration. Si vous utilisez Zsh (défaut sur macOS récents), vérifiez avec cat ~/.zshrc. Si vous utilisez Bash, ce sera plutôt cat ~/.bash_profile ou ~/.bashrc. Assurez-vous que la ligne eval "$(rbenv init - ...)" y figure bien, généralement à la fin.
Les solutions pour corriger définitivement votre PATH
Une fois le diagnostic posé, la correction est souvent très simple. Voici les cas les plus courants et leur solution :
- Cause n°1 (la plus fréquente) : Vous avez bien modifié le fichier de configuration, mais vous n'avez pas redémarré votre terminal. Les fichiers comme
.zshrcne sont lus qu'au démarrage d'une nouvelle session de terminal. Solution : Fermez complètement votre fenêtre de terminal et ouvrez-en une nouvelle. - Cause n°2 : La ligne d'initialisation est manquante ou dans le mauvais fichier. Solution : Relancez la commande
rbenv init, copiez la ligne qu'elle vous indique et ajoutez-la à la fin du bon fichier de configuration pour votre shell (~/.zshrcpour Zsh,~/.bash_profilepour Bash). Puis, redémarrez votre terminal.
Dans de très rares cas, l'installation de rbenv elle-même pourrait être corrompue. Vous pouvez le vérifier avec la commande which rbenv. Elle devrait vous retourner un chemin (ex: /usr/local/bin/rbenv). Si elle ne retourne rien, il faut reprendre l'installation de rbenv. Savoir déboguer ce type de problème est une compétence fondamentale pour un développeur. Vous venez d'apprendre l'une des leçons les plus importantes sur la configuration d'un environnement de travail.