Warum habe ich / wie kann ich diesen Fehler beheben: "shell_session_update: Befehl nicht gefunden"

TL; DR: Stellen Sie sicher, dass RVM mindestens 1.26.11 auf dem neuesten Stand ist, indem Sie den Befehl erneut installieren oder ausgeben rvm get headund nur einmal pro Terminalumgebung initialisiert werden.

Ergebnis

Schließlich konnte ich meine Umgebung reparieren. Ich werde einige Informationen zu meinem spezifischen Problem veröffentlichen, um einigen zu helfen, auch wenn andere das gleiche Symptom, aber eine andere Ursache haben können.

Ursache

Ein Teil des Hauptproblems war von RVM und wie es für meine Befehlszeilenumgebungen initialisiert wurde. Ich hatte ein paar verschiedene Wege gefunden, dies zu tun, zumal eine zusätzliche Methode speziell für die fishShell-Umgebung entwickelt wurde.

Es scheint, dass die Hauptursache entweder war:

• RVM mehr als einmal initialisieren, da ich mehrere Anweisungen hatte, eine pro Terminalkonfigurationsdatei, und aufgrund ihrer Verkettung waren mir die anderen nicht bewusst, die automatisch hinzugefügt wurden.
• Oder es wurden irgendwie Anweisungen hinzugefügt, die die Initialisierung für eine Terminalumgebung mischten fishund in meiner anderen Terminalumgebung ausgeführt wurden bash, oder umgekehrt. Dies ist in meinen Details unten zu sehen, wo der gebrochene bashPATH einige der durch :s begrenzten Pfade hat, andere jedoch auch durch Leerzeichen eingeschlossen wurden, was eine falsche Syntax ist bash, aber korrekt ist fish.
• Oder beides geschah!

Der andere Teil des Wurzelproblems war, dass sich anscheinend ein RVM / direnv-bezogener Fehler in Bezug auf die Trap-Funktion eingeschlichen hat. Ich bin wahrscheinlich wieder auf dieses Problem gestoßen, als ich eine der anderen problematischen Versionen von RVM hatte, die verursacht werden konnte durch:

• Eine Neuinstallation: curl -sSL https://get.rvm.io | bash
• Ein manuelles Update: rvm get head
• Ein automatisches Update (das ich gerade gemacht hatte) durch Hinzufügen rvm_autoupdate_flag=2von~/.rvmrc

Dieses Problem sollte am 30. März 2016 oder Release 1.26.11 behoben sein:

• GitHub - direnv / direnv - Problem: / bin / bash: shell_session_update: Befehl nicht gefunden # 210
• GitHub - rvm / rvm - Problem: RVM überschreibt die in OS X El Capitan # 3540 definierte Bash-Exit-Falle
• GitHub - rvm / rvm - Problem: OSX (El Capitan) rvm-Quelle in .bash_profile-Ruinen .bash_history-Schreiben (Terminal.app) # 3560
• GitHub - rvm / rvm - Pull Request: Fehler bei bash-Sitzungen unter OSX 10.11+ # 3627
• GitHub - rvm / rvm - Problem: sollte sich mit ~ / .bash_sessions_disable # 3628 befassen
• GitHub - rvm / rvm - Problem: Fish Shell-Fehler nach stabilem Update # 3655
• GitHub - rvm / rvm - Problem: Trap nicht mit einem nicht vorhandenen Befehl # 3657
• GitHub - rvm / rvm - Release: Vergleich der Änderungen 1.26.11..master
• Wiederherstellen der Wiederherstellung von shell_session_update auf EXIT, Update # 3657, Update # 3628

Die Geschichte

Nachdem ich mit den GNU-Dienstprogrammen gekämpft hatte, um eine vollständige Suche des Dateisystems durchzuführen, habe ich Atom dazu verwendet, um mehr Erfolg zu erzielen, und fand heraus, dass das einzige Vorkommen shell_session_updatein der /etc/bashrc_Apple_Terminalvon Zanchey erwähnten Datei (außer den Protokolldateien) gefunden wurde und derartige). Ich bin auch nicht sicher, warum das ausgeführt wurde, weil ich iTerm (2) verwendet habe und der Wert $TERM_PROGRAMin diesem Fall ist iTerm.appund nicht Apple_Terminal.

Es half auch nicht, dass ich aus irgendeinem Grund die RVM-Installation mehr als einmal verwalten musste und den Installationsprozess durchging, der anscheinend bereits einigen 'dotfiles' eine Konfiguration hinzufügt, bei der ich auch einige Zeilen manuell hinzugefügt hatte .

Außerdem hatte ich auf meinem Mac eine .bashrcDatei erstellt und darauf verlinkt .bash_profile, da sie anscheinend nicht standardmäßig vorhanden war. Ich hatte zuvor auf einem Linux-System gelesen, das durch Konvention .bash_profilefür einige Anpassungen geeignet ist und .bashrcfür andere geeignet ist, z. B. für die Definition von Aliasnamen und Funktionen von Benutzern oder umgekehrt. Ich war also nicht daran gewöhnt, in die .bash_profileDatei zu schauen und vor allem nicht in die .profileDatei, alles im Benutzerverzeichnis, das ein ähnliches System kopiert. Vergessen wir auch nicht ein path_helperist in der Mischung (!), Schien aber zu keinem Problem beizutragen.

Die möglichen Möglichkeiten zum Einrichten der Umgebung, die korrekt oder nicht korrekt sind, lauten wie folgt:

• [[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
• export PATH="$PATH:$HOME/.rvm/bin"(als letzte Zeile, in der die PATHVariable geändert wird, unmittelbar bevor der Benutzer die Kontrolle übergibt.
• rvm default( PATHMuss auch die letzte modifizierende Zeile sein. Von: StackOverflow - Immer "Warning! PATH ist nicht richtig eingerichtet", wenn Sie rvm verwenden, verwenden Sie 2.0.0 --default. )

Mehr Details

Für mehr unglaubliche Ausführlichkeit finden Sie hier einige Beispielpfade, die ich beim Debuggen des Problems zwischen verschiedenen Umgebungen erfasst habe:

Original (gebrochener) Fisch PFAD

/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/ Behälter

"Natürlich" besser Fisch PFAD

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

Ursprünglicher (gebrochener) bash PFAD

/libexec/gnubin:/bin:/Users/username/.rvm/gems/ruby-2.0.0-p648/bin /Users/username/.rvm/gems/ruby-2.0.0-p648@global/bin / Benutzer /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

"Manuell" Fixed 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:/User/benutzername/.rvm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin: /sbin:/usr/local/munki:/Users/username/.rvm/bin:/Users/username/.rvm/bin

'Natürlich' besser bash PFAD

/ 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

Anmerkungen:

• Die 'Originale' waren vom Starten der brandneuen Umgebung in einem Befehlszeileninterpreter, während das Problem auftrat.
• Das "Handbuch" ist natürlich, wenn ich die falsche Pfadzeichenfolge genommen habe, die Syntaxfehler korrigiert habe und den Interpreter besser bedient habe, also wusste ich, was zu erwarten ist, wenn ich die Ursache weiter beheben kann.
• Die 'natürlichen' waren, als ich zum ersten Mal das Laden meiner Konfigurationsdateien für die Terminalumgebung wie .bashrcusw. übersprang und sie schließlich ausgeführt hatte, nachdem das Problem behoben wurde.

Ich hatte auch das gleiche Problem. Später stellte ich fest, dass bereits ein Problem in rvm repo vorhanden ist. Und sie haben es in einer der Pull-Anfragen behoben.

Um dies zu beheben, aktualisieren Sie den rvm entweder auf die neueste Version oder verweisen Sie auf die aktuelle Entwicklungsversion.

rvm get head 

Weitere Details finden Sie in diesem Beitrag .