TL; DR: Переконайтесь, що RVM оновлюється щонайменше до 1.26.11 шляхом перевстановлення або видачі команди rvm get head та ініціалізується лише один раз у середовищі терміналу.
Результат
Врешті-решт я зміг виправити своє оточення. Я опублікую деяку інформацію, що стосується моєї конкретної проблеми, намагаючись допомогти деяким, хоча інші можуть мати той же симптом, але іншу першопричину.
Причина
Одна частина кореневої проблеми виходила з RVM, і як вона ініціалізувалася для моїх середовищ командного рядка. Я знайшов кілька різних способів зробити це, тим більше, що один додатковий метод був спеціально створений для fishсередовища оболонки.
Здається, першопричиною було:
- ініціалізувати RVM не один раз, тому що у мене було кілька операторів, по одному на файл конфігурації терміналу, і через те, як вони були пов'язані ланцюгом, я не знав про інші, які автоматично додавалися.
- Або якимось чином додані заяви, які змішують ініціалізацію для одного термінального середовища, скажімо
fish, і запускаються в моєму іншому термінальному середовищі bash, або навпаки. Це можна побачити в моїх деталях нижче, де зламаний bashPATH має деякі шляхи, розмежовані :s, але інші також включаються пробілами, для яких неправильний синтаксис bash, але правильний для fish.
- Або обидва траплялися!
Тоді іншою частиною кореневої проблеми було те, що, здається, нещодавно виникла помилка, пов’язана з RVM / direnv, щодо функції пастки. Можливо, я знову стикався з цим, маючи один із інших проблемних випусків 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 це в суміші (!), Але, здається, не сприяє виникненню проблем.
Можливі способи налаштування навколишнього середовища, які можуть бути правильними чи ні, такі:
Детальніше
Для отримання більш неймовірної багатослівності, ось кілька прикладних шляхів, які я захопив між собою в різних середовищах під час налагодження проблеми:
Оригінальна (зламана) риба ПАТ
/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/ бункер
"Природно" краща риба PATH
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
Оригінальний (ламаний) баш 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 / Користувачі /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
"Природно", краще баш 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
Примітки:
- "Оригінал" починав із створення абсолютно нового середовища в будь-якому інтерпретаторі командного рядка, не маючи при цьому проблеми.
- "Посібник", звичайно, коли я взяв неправильний рядок шляху, виправив синтаксичні помилки та побачив більш правильну роботу інтерпретатора, тому я знав, що чекати, продовжуючи виправляти першопричину.
- "Природні" з'явилися, коли я вперше пропустив завантаження файлів конфігурації оточуючого терміналу, таких як
.bashrcі так далі, а потім, зрештою, запустив їх після вирішення проблеми.
shell_session_updateє функцією Bash, встановленою OS X в/etc/bashrc_Apple_Terminal, тому, імовірно, щось у командах Bash, що виконує RVM, виробляє її як вихід.