web-dev-qa-db-fra.com

Pourquoi ai-je / comment puis-je corriger cette erreur: "Shell_session_update: command not found"

Contexte

J'utilise Ruby 2.x et Rails 4.x sur un MacBook sous OS X El Capitan (10.11.3), à l'aide du poisson Shell, en utilisant l'intégration indiquée sur cette page: RVM - Coquille de poisson (Intégration)

Problème

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

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

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

J'ai effectué une recherche de texte rapide dans le fichier de fonctions rvm.fish, dans le répertoire .config/fish et également dans l'exécutable principal $HOME/.rvm/bin/rvm, et je n'ai pas vu de commande telle que Shell_session_update être appelée directement dans ce fichier.

Question

Est-ce que quelqu'un sait pourquoi cela se produit et comment je peux y remédier? Je suis une personne qui aime régler les problèmes qui se présentent à moi, de sorte que seules les actions sur lesquelles je dois agir apparaissent en face de moi. J'aimerais donc supprimer ce message d'erreur/avertissement. :)

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

macosshellrvmfish
24
Pysis

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 en cours d’initialisation une fois par environnement de terminal.

Résultat

Finalement, j'ai pu réparer mon environnement. Je publierai des informations relatives à mon problème spécifique afin d’aider certaines personnes, même si d’autres peuvent avoir le même symptôme mais une autre cause fondamentale.

Cause

Une partie du problème racine provenait de RVM et de la manière dont il était initialisé pour mes environnements de ligne de commande. J'avais trouvé différentes façons de le faire, en particulier depuis qu'une méthode supplémentaire avait été spécialement conçue pour l'environnement Shell fish.

Il semble que la cause principale soit:

  • initialiser plusieurs fois RVM, car j’avais plusieurs instructions, une par fichier de configuration de terminal, et à cause de la façon dont elles étaient chaînées, je n’étais pas au courant des autres qui ont été ajoutées automatiquement.
  • Ou, d'une manière ou d'une autre, des instructions ont été ajoutées qui mélangeaient l'initialisation pour un environnement terminal, par exemple fish, et étaient exécutées dans mon autre environnement terminal, bash ou vice versa. Ceci est indiqué dans les détails ci-dessous, où le chemin bash_Port rompu comporte des chemins délimités par :s, mais d'autres sont également inclus par des espaces, ce qui représente une syntaxe incorrecte pour bash, mais correcte pour fish.
  • Ou les deux se passaient!

Ensuite, l’autre partie du problème fondamental est qu’il semble qu’un bug lié à RVM/direnv s’est récemment glissé au sujet de la fonction piège. J'ai probablement rencontré à nouveau cela en ayant l'une des autres versions problématiques de RVM qui pourrait être causée 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 corrigé à compter du 30 mars 2016 ou de la version 1.26.11:

L'histoire

Après s'être battu avec les utilitaires GNU pour effectuer une recherche complète du système de fichiers, jetant un coup d'œil à l'intérieur du contenu du fichier, j'ai utilisé Atom pour obtenir plus de succès et constaté que la seule occurrence de Shell_session_update avait été trouvée dans le /etc/bashrc_Apple_Terminal. fichier mentionné par Zanchey (en plus des fichiers d’historique et autres). Je ne sais pas non plus pourquoi cela a été exécuté parce que j'utilisais iTerm (2), et la valeur de $TERM_PROGRAM dans ce cas est iTerm.app et non Apple_Terminal.

Cela n’a pas non plus aidé que, pour une raison quelconque, j’ai eu à gérer l’installation de RVM plus d’une fois, en passant par le processus d’installation, ce qui apparemment ajoute déjà la configuration à plusieurs "fichiers de points", où j’avais aussi ajouté manuellement une ou plusieurs lignes. .

Parallèlement à cela, j'avais créé un fichier .bashrc auquel je m'étais lié à partir de .bash_profile sur mon Mac, puisqu'il n'existait apparemment pas par défaut. Auparavant, j'avais lu sur un système Linux que, par convention, .bash_profile convenait à certaines personnalisations et .bashrc à d'autres, comme la définition d'alias et de fonctions d'utilisateurs, ou inversement. Je n’étais donc pas habitué à regarder à l’intérieur du fichier .bash_profile, et surtout pas du fichier .profile, tous dans le répertoire utilisateur, que le même système copie également. N'oublions pas non plus qu'un path_helper est dans le mélange (!), Mais ne semble pas avoir contribué à créer de problèmes.

Les manières possibles de configurer l'environnement, qu'elles soient correctes ou non, sont les suivantes:

Plus de détails

Pour plus de détails, 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/usr/sbin/sbin/usr/local/munki /Users/username/.rvm/ poubelle

'Naturellement' meilleur poisson PATH

/ usr/local/opt/coreutils/libexec/gnubin/usr/local/opt/findutils/bin/usr/local/bin/usr/bin/bin/usr/sbin/sbin/usr/local/munki

bash d'origine (brisé) PATH

/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/usr/sbin/sbin/usr/local/munki : /Users/username/.rvm/bin

'Manuellement' a corrigé bash PATH

/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/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/munki

Remarques:

  • Les 'originaux venaient du lancement du nouvel environnement dans l'un des interprètes en ligne de commande alors que le problème se posait.
  • Le "manuel" est bien sûr lorsque j'ai pris la chaîne de chemin incorrect, corrigé les erreurs de syntaxe et constaté un fonctionnement plus correct de l'interpréteur. Je savais donc à quoi m'attendre pour continuer à corriger la cause fondamentale.
  • Les "caractéristiques naturelles" datent de la première fois où j'ai ignoré le chargement des fichiers de configuration de mon environnement terminal, tels que .bashrc, etc., puis je les ai exécutés une fois le problème résolu.
40
Pysis

Moi aussi j'ai eu le même problème. Plus tard, j’ai trouvé qu’un problème était déjà présent dans rvm repo pour cela. Et ils l'ont corrigé dans l'une des demandes d'extraction.

Pour résoudre ce problème, vous devez soit mettre à niveau la version la plus récente, soit la pointer vers la révision de développement actuelle.

rvm get head

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

5
Ajit Singh