TL; DR: убедитесь, что RVM обновлен по крайней мере до 1.26.11, переустановив или выполнив команду rvm get head , и инициализируется только один раз для среды терминала.
Результат
В конце концов я смог исправить свое окружение. Я опубликую некоторую информацию, относящуюся к моей конкретной проблеме, чтобы помочь некоторым, даже если у других может быть тот же симптом, но другая основная причина.
причина
Одна часть основной проблемы исходила от RVM и от того, как она инициализировалась для моей среды командной строки. Я нашел несколько разных способов сделать это, тем более что один дополнительный метод был специально разработан для среды обитания fish раковин.
Кажется, основной причиной было либо:
- инициализировать RVM более одного раза, потому что у меня было несколько операторов, по одному на файл конфигурации терминала, и из-за того, как они были связаны, я не знал о других, которые были автоматически добавлены.
- Или, так или иначе, были добавлены операторы, которые смешивали инициализацию для одной терминальной среды, скажем,
fish , и выполнялись в моей другой терминальной среде, bash или наоборот. Это можно увидеть в моих подробностях ниже, где в PATH для разбитого bash есть некоторые пути, разделенные : 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 упомянутом Занчей (помимо файлов истории и тому подобного). Я также не уверен, почему это выполнялось, потому что я использовал 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 и т.д., А затем в конечном итоге запустил их после того, как проблема была решена.
