TL; DR: assurez-vous que RVM est à jour au moins à 1.26.11 en réinstallant ou en émettant la commande rvm get head, et n'est initialisé qu'une seule fois par environnement de terminal.
Résultat
Finalement, j'ai pu réparer mon environnement. Je publierai quelques informations concernant mon problème spécifique dans le but d'aider certains, même si d'autres peuvent avoir le même symptôme mais une autre cause profonde.
Cause
Une partie du problème racine provenait de RVM et de la façon dont il était initialisé pour mes environnements de ligne de commande. J'avais trouvé deux façons différentes de le faire, d'autant plus qu'une méthode supplémentaire a été spécialement conçue pour l' fishenvironnement shell.
Il semble que la cause profonde soit:
- initialiser RVM plus d'une fois, car j'avais plusieurs instructions, une par fichier de configuration de terminal, et en raison de la façon dont elles étaient chaînées, je ne connaissais pas les autres qui étaient automatiquement ajoutées.
- Ou, en quelque sorte, des déclarations ont été ajoutées qui mélangeaient l'initialisation pour un environnement de terminal, disons
fish, et étaient exécutées dans mon autre environnement de terminal bash, ou vice versa. Cela peut être vu dans mes détails ci-dessous où le bashCHEMIN cassé a certains des chemins délimités par :s, mais d'autres également inclus par des espaces, ce qui est une syntaxe incorrecte pour bash, mais correcte pour fish.
- Ou les deux se passaient!
Ensuite, l'autre partie du problème racine était qu'il semble qu'un bogue lié à RVM / direnv s'est glissé récemment concernant la fonction de déroutement. J'ai probablement rencontré cela à nouveau en ayant l'une des autres versions problématiques de RVM qui pourraient être causées par:
- Une réinstallation:
curl -sSL https://get.rvm.io | bash
- Une mise à jour manuelle:
rvm get head
- Une mise à jour automatique (que je venais de faire) en ajoutant
rvm_autoupdate_flag=2à~/.rvmrc
Ce problème devrait être résolu à partir du 30 mars 2016 ou de la version 1.26.11:
L'histoire
Après avoir combattu avec les utilitaires GNU pour effectuer une recherche complète du système de fichiers, jetant un œil à l'intérieur du contenu du fichier, j'ai utilisé Atom pour faire plus de succès, et j'ai constaté que la seule occurrence de shell_session_updateétait trouvée dans le /etc/bashrc_Apple_Terminalfichier mentionné par Zanchey (en plus des fichiers d'historique) et autres choses de ce genre). Je ne sais pas non plus pourquoi cela a été exécuté parce que j'utilisais iTerm (2), et la valeur de $TERM_PROGRAMdans ce cas est iTerm.appet non Apple_Terminal.
Cela n'a pas non plus aidé que, pour une raison quelconque, j'ai dû gérer l'installation RVM plus d'une fois, en passant par le processus d'installation, qui apparemment ajoute déjà la configuration à plusieurs `` fichiers de points '', où j'avais également ajouté manuellement certaines ou les lignes .
Parallèlement à cela, j'avais créé un .bashrcfichier et je l'avais lié à partir .bash_profilede mon Mac, car il n'existait apparemment pas par défaut. J'avais déjà lu sur un système Linux qui, par convention, .bash_profileest bon pour certaines personnalisations et .bashrcbon pour d'autres comme la définition d'alias et de fonctions utilisateur, ou vice versa. Je n'étais donc pas habitué à regarder à l'intérieur du .bash_profilefichier, et surtout pas le .profilefichier, le tout dans le répertoire utilisateur, que le système similaire copie également. N'oublions pas non plus qu'un path_helperest dans le mix (!), Mais ne semble pas avoir contribué à des problèmes.
Les façons possibles de configurer l'environnement, qui peuvent être correctes ou non, sont les suivantes:
Plus de détails
Pour une verbosité plus incroyable, voici quelques exemples de chemins que j'ai capturés entre différents environnements lors du débogage du problème:
CHEMIN de poisson original (cassé)
/Users/username/.rvm/gems/ruby-2.0.0-p648/bin /Users/username/.rvm/gems/ruby-2.0.0-p648@global/bin /Users/username/.rvm/rubies/ ruby-2.0.0-p648 / bin /Users/username/.rvm/bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki /Users/username/.rvm/ poubelle
Un poisson "naturellement" meilleur
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
Chemin de bash original (cassé)
/libexec/gnubin:/bin:/Users/username/.rvm/gems/ruby-2.0.0-p648/bin /Users/username/.rvm/gems/ruby-2.0.0-p648@global/bin / Users /username/.rvm/rubies/ruby-2.0.0-p648/bin /Users/username/.rvm/bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki : /Users/username/.rvm/bin
CHEMIN BASH fixe 'manuellement'
/libexec/gnubin:/bin:/Users/username/.rvm/gems/ruby-2.0.0-p648/bin:/Users/username/.rvm/gems/ruby-2.0.0-p648@global/bin: /Users/username/.rvm/rubies/ruby-2.0.0-p648/bin:/Users/username/.rvm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin: /sbin:/usr/local/munki:/Users/username/.rvm/bin:/Users/username/.rvm/bin
"Naturellement" mieux bash PATH
/ usr / local / opt / coreutils / libexec / gnubin: / usr / local / opt / findutils / bin: / usr / local / opt / coreutils / libexec / gnubin: / usr / local / opt / findutils / bin: / usr / local / local / bin: / usr / bin: / bin: / usr / sbin: / sbin: / usr / local / munki
Remarques:
- Les `` originaux '' provenaient du démarrage du tout nouvel environnement dans l'un ou l'autre des interprètes de ligne de commande tout en ayant le problème.
- Le 'manuel' est bien sûr quand j'ai pris la chaîne de chemin incorrecte, corrigé les erreurs de syntaxe et vu un fonctionnement plus correct de l'interpréteur, donc je savais à quoi m'attendre en continuant à corriger la cause racine.
- Les `` naturels '' datent du moment où j'ai ignoré le chargement de mes fichiers de configuration d'environnement terminal tels que
.bashrcet ainsi de suite, puis les ai finalement exécutés une fois le problème résolu.
shell_session_updateest une fonction Bash installée par OS X dans/etc/bashrc_Apple_Terminal, donc il est probable que quelque chose dans les commandes Bash que RVM exécute la produit en sortie.