Contexte

J'entre dans Ruby 2.x et Rails 4.x, sur un MacBook utilisant OS X El Capitan (10.11.3), en utilisant le shell de poisson, en utilisant l'intégration répertoriée sur cette page: RVM - Fish Shell (Intégration)

Problème

Lors de l' exécution de diverses commandes telles que rvm version, rvm install ..., rvm use ..., rvm --default ..., etc., je reçois le message d'erreur suivant:

/var/folders/2w/zhgybz7d25s1gdy41qdxwp48001gfh/T/rvm.fish.Pqd0CuZRJW: shell_session_update: command not found

La recherche rapide sur Google ne renvoie aucun résultat connexe qui pourrait m'aider à identifier et / ou à résoudre le problème, comme cela a fonctionné pour bon nombre de mes autres problèmes de configuration du développement.

J'ai fait une recherche de texte rapide dans le rvm.fishfichier de fonctions, sous le .config/fishrépertoire, et également à l'intérieur de l' $HOME/.rvm/bin/rvmexécutable principal, et je n'ai pas vu de commande telle shell_session_updatequ'être appelée directement dans ce fichier.

Question

Est-ce que quelqu'un sait pourquoi cela se produit et comment y remédier? Je suis une personne qui aime réparer les choses devant moi, de sorte que seules les choses sur lesquelles je dois agir apparaissent devant moi, donc je voudrais supprimer ce message d'erreur / d'avertissement. :)

PS Une version Ruby particulière (2.0.0) que j'essayais d'installer et d'utiliser, semble fonctionner correctement, même dans la même session de terminal (iTerm (2)), sans avoir à la redémarrer. Depuis, j'ai fermé celle-ci et j'ai créé une nouvelle session de terminal, et je vois toujours le message apparaître lors de l'exécution des différentes commandes susmentionnées.

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:

• GitHub - direnv / direnv - Problème: / bin / bash: shell_session_update: commande introuvable # 210
• GitHub - rvm / rvm - Problème: RVM écrase l'interruption de sortie bash définie dans OS X El Capitan # 3540
• GitHub - rvm / rvm - Problème: source rvm OSX (El Capitan) dans les ruines .bash_profile .bash_history écrit (Terminal.app) # 3560
• GitHub - rvm / rvm - Pull Request: bogue avec les sessions bash sur OSX 10.11+ # 3627
• GitHub - rvm / rvm - Problème: devrait traiter avec ~ / .bash_sessions_disable # 3628
• GitHub - rvm / rvm - Problème: erreur de shell de poisson après la mise à jour stable # 3655
• GitHub - rvm / rvm - Problème: ne pas intercepter avec une commande inexistante # 3657
• GitHub - rvm / rvm - Release: Comparaison des changements 1.26.11..master
• restauration de nettoyage du hook shell_session_update sur EXIT, mise à jour # 3657, mise à jour # 3628

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:

• [[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
• export PATH="$PATH:$HOME/.rvm/bin"(comme la dernière ligne qui modifie la PATHvariable juste avant que le contrôle ne soit remis à l'utilisateur.
• rvm default( PATHDoit également être la dernière ligne de modification. De: StackOverflow - Obtenir "Attention! PATH n'est pas correctement configuré" lorsque vous utilisez rvm, utilisez 2.0.0 --default )

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.

Moi aussi, j'ai eu le même problème. Plus tard, j'ai constaté qu'il y avait déjà un problème dans le dépôt rvm pour cela. Et ils l'ont corrigé dans l'une des demandes de tirage.

Pour résoudre ce problème, mettez à niveau le rvm vers la dernière version ou pointez-le sur la révision de développement actuelle.

rvm get head

Pour plus de détails, reportez-vous à cet article .