TL; DR: убедитесь, что RVM обновлен как минимум до 1.26.11, переустановив или выполнив команду rvm get head, и инициализируется только один раз для среды терминала.
Результат
В конце концов я смог исправить свое окружение. Я опубликую некоторую информацию, относящуюся к моей конкретной проблеме, чтобы помочь некоторым, даже если у других может быть тот же симптом, но другая основная причина.
причина
Одна часть основной проблемы исходила от RVM и от того, как она инициализировалась для моей среды командной строки. Я нашел несколько разных способов сделать это, тем более что один дополнительный метод был специально разработан для fishсреды оболочки.
Кажется, основной причиной было либо:
- инициализация RVM более одного раза, потому что у меня было несколько операторов, по одному на файл конфигурации терминала, и из-за того, как они были связаны, я не знал о других, которые были автоматически добавлены.
- Или, так или иначе, были добавлены операторы, которые, скажем
fish, смешивали инициализацию для одной терминальной среды и выполнялись в другой терминальной среде bash, или наоборот. Это можно увидеть в моих подробностях ниже, где сломанный bashPATH имеет некоторые пути, разделенные символом :s, но другие также включают пробелы, что является неправильным синтаксисом для bash, но корректным для fish.
- Или оба происходили!
Затем другая часть проблемы с корнем заключалась в том, что, похоже, недавно возникла ошибка, связанная с RVM / direnv, в отношении функции trap. Я, вероятно, столкнулся с этим снова, имея один из других проблемных выпусков RVM, который мог быть вызван:
- Переустановка:
curl -sSL https://get.rvm.io | bash
- Обновление вручную:
rvm get head
- Автоматическое обновление (что я только что сделал), добавив
rvm_autoupdate_flag=2в~/.rvmrc
Эта проблема должна быть исправлена по состоянию на 30 марта 2016 г. или выпуск 1.26.11:
История
После борьбы с утилитами GNU для полного поиска в файловой системе, просмотра содержимого файла, я использовал Atom, чтобы добиться большего успеха, и обнаружил, что единственное вхождение shell_session_updateбыло найдено в /etc/bashrc_Apple_Terminalфайле, упомянутом Zanchey (кроме файлов истории). и тому подобное). Я также не уверен, почему это выполнялось, потому что я использовал iTerm (2), а значение $TERM_PROGRAMв этом случае есть iTerm.appи нет Apple_Terminal.
Также не помогло то, что мне по какой-то причине пришлось управлять установкой RVM более одного раза, проходя процесс установки, который, очевидно, уже добавляет конфигурацию к нескольким «точечным файлам», где я также вручную добавил некоторые или строки ,
Наряду с этим я создал .bashrcфайл и связался с ним .bash_profileна моем Mac, поскольку он, по-видимому, не существует по умолчанию. Ранее я читал о системе Linux, которая, по соглашению, .bash_profileхороша для некоторых настроек и .bashrcхороша для других, таких как определение псевдонимов и функций пользователя, или наоборот. Поэтому я не привык заглядывать в .bash_profileфайл, особенно в .profileфайл, в каталог пользователя, который также копирует аналогичная система. Давайте также не будем забывать, что path_helperесть в миксе (!), Но, похоже, никаких проблем не возникло .
Возможные способы настройки среды, которые могут быть правильными или нет, следующие:
Подробнее
Для более невероятного многословия, вот несколько примеров путей, которые я нашел в разных средах при отладке проблемы:
Оригинальная (сломанная) рыба PATH
/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/ бункер
«Естественно» лучше рыбы ПУТЬ
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
Оригинальный (сломанный) Баш ПУТЬ
/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
«Вручную» Исправлена ошибка 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
«Естественно» лучше Баш ПУТЬ
/ USR / местные / Opt / Coreutils / libexec / gnubin: / USR / местные / Opt / Findutils / бен: / USR / местные / Opt / Coreutils / libexec / gnubin: / USR / местные / Opt / Findutils / бен: / USR / местные / бен: / USR / бен: / бен: / USR / SBIN: / SBIN: / USR / местные / munki
Заметки:
- «Оригинал» был от запуска новой среды в любом интерпретаторе командной строки при наличии проблемы.
- «Руководство» - это, конечно, когда я взял неверную строку пути, исправил синтаксические ошибки и увидел более правильную работу интерпретатора, поэтому я знал, чего ожидать, продолжая устранять основную причину.
- Естественные были с того момента, когда я сначала пропустил загрузку файлов конфигурации среды терминала, таких как
.bashrcи т. Д., А затем в конечном итоге запустил их после того, как проблема была решена.
shell_session_updateявляется функцией Bash, установленной OS X в/etc/bashrc_Apple_Terminal, так что, вероятно, что-то в командах Bash, которые запускает RVM, производит ее в качестве вывода.