TL; DR: Upewnij się, że RVM jest aktualny do wersji co najmniej 1.26.11, ponownie instalując lub wydając polecenie rvm get head, i jest inicjowany tylko raz na środowisko terminala.
Wynik
W końcu udało mi się naprawić moje środowisko. Zamierzam opublikować pewne informacje dotyczące mojego konkretnego problemu, starając się pomóc niektórym, nawet jeśli inni mogą mieć ten sam objaw, ale inną podstawową przyczynę.
Przyczyna
Jedna część problemu root pochodziła z RVM i jak została zainicjowana dla moich środowisk wiersza poleceń. Znalazłem kilka różnych sposobów, aby to zrobić, zwłaszcza, że stworzono jedną dodatkową metodę dla fishśrodowiska powłoki.
Wydaje się, że główną przyczyną była albo:
- inicjowanie RVM więcej niż jeden raz, ponieważ miałem wiele instrukcji, po jednej na plik konfiguracyjny terminala, a ze względu na sposób ich łączenia, nie wiedziałem o innych, które zostały automatycznie dodane.
- Lub, w jakiś sposób, dodano instrukcje, które mieszały inicjację dla jednego środowiska terminalowego, powiedzmy
fish, i były uruchamiane w moim innym środowisku terminalowym bash, lub odwrotnie. Można to zobaczyć w moich szczegółach poniżej, gdzie zepsuta bashŚCIEŻKA ma niektóre ścieżki ograniczone przez :s, ale inne zawierają również spacje, co jest niepoprawną składnią bash, ale poprawną dla fish.
- Albo oboje się zdarzali!
Następnie drugą częścią problemu root było to, że wydaje się, że błąd związany z RVM / direnv pojawił się ostatnio w związku z funkcją pułapki. Prawdopodobnie spotkałem się z tym ponownie, mając jedną z innych problematycznych wersji RVM, które mogły być spowodowane przez:
- Ponowna instalacja:
curl -sSL https://get.rvm.io | bash
- Aktualizacja ręczna:
rvm get head
- Automatyczna aktualizacja (którą właśnie wykonałem) poprzez dodanie
rvm_autoupdate_flag=2do~/.rvmrc
Ten problem powinien zostać rozwiązany od 30 marca 2016 r. Lub w wersji 1.26.11:
Historia
Po walce z narzędziami GNU, aby przeprowadzić pełne wyszukiwanie systemu plików, zaglądając do zawartości pliku, użyłem Atomu, aby osiągnąć większy sukces, i odkryłem, że jedyne wystąpienie shell_session_updateznaleziono w /etc/bashrc_Apple_Terminalpliku wspomnianym przez Zancheya (oprócz plików historii oraz taki). Nie jestem również pewien, dlaczego to było uruchamiane, ponieważ korzystałem z iTerm (2), a wartość $TERM_PROGRAMw tym przypadku jest iTerm.appi nie Apple_Terminal.
Nie pomogło mi również to, że z jakiegoś powodu musiałem zarządzać instalacją RVM więcej niż raz, przechodząc przez proces instalacji, który najwyraźniej dodaje już konfigurację do kilku „plików dot”, w których również ręcznie dodałem niektóre lub wiersze .
Oprócz tego utworzyłem .bashrcplik i podlinkowałem go z .bash_profilemojego komputera Mac, ponieważ najwyraźniej domyślnie nie istniał. Wcześniej czytałem na temat systemu Linux, który zgodnie z konwencją .bash_profilejest dobry dla niektórych dostosowań i .bashrcjest dobry dla innych, takich jak definiowanie aliasów i funkcji użytkownika lub odwrotnie. Nie byłem więc przyzwyczajony do zaglądania do .bash_profilepliku, a zwłaszcza do .profilepliku, wszystko w katalogu użytkownika, który również kopiuje podobny system. Nie zapominajmy też, że a path_helperjest w miksie (!), Ale wydaje się, że nie przyczynia się do żadnych problemów.
Możliwe sposoby skonfigurowania środowiska, które mogą być poprawne lub nie, są następujące:
Więcej szczegółów
Aby uzyskać bardziej niewiarygodną szczegółowość, oto kilka przykładowych ścieżek przechwyconych przez różne środowiska podczas debugowania problemu:
Oryginalna (łamana) ŚCIEŻKA ryb
/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/ kosz
„Naturalnie” lepsza ŚCIEŻKA dla ryb
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
Oryginalna (zepsuta) ŚCIEŻKA bashu
/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
„Ręcznie” Naprawiono ścieżkę bash
/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
„Naturalnie” lepsza ŚCIEŻKA uderzenia
/ 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
Uwagi:
- „Oryginały” pochodziły od uruchomienia zupełnie nowego środowiska w dowolnym z interpreterów wiersza poleceń, mając problem.
- „Podręcznik” jest oczywiście wtedy, gdy wziąłem niepoprawny ciąg ścieżki, naprawiłem błędy składniowe i zobaczyłem poprawniejsze działanie interpretera, więc wiedziałem, czego się spodziewać, gdy będę kontynuować naprawianie pierwotnej przyczyny.
- Naturalne były od momentu, gdy po raz pierwszy pominąłem ładowanie plików konfiguracyjnych środowiska terminalowego, takich jak
.bashrci tak dalej, a potem ostatecznie je uruchomiłem po rozwiązaniu problemu.
shell_session_updatejest funkcją Bash zainstalowaną przez OS X/etc/bashrc_Apple_Terminal, więc prawdopodobnie coś w komendach Bash, które uruchamia RVM, wytwarza ją jako wynik.