TL; DR: Đảm bảo RVM được cập nhật tối thiểu 1.26.11 bằng cách cài đặt lại hoặc ban hành lệnh rvm get headvà chỉ được khởi tạo một lần cho mỗi môi trường đầu cuối.
Kết quả
Cuối cùng, tôi đã có thể sửa chữa môi trường của tôi. Tôi sẽ đăng một số thông tin liên quan đến vấn đề cụ thể của tôi trong nỗ lực giúp đỡ một số người, mặc dù những người khác có thể có cùng một triệu chứng nhưng nguyên nhân gốc rễ khác.
Nguyên nhân
Một phần của vấn đề gốc là từ RVM và cách nó được khởi tạo cho môi trường dòng lệnh của tôi. Tôi đã tìm thấy một vài cách khác nhau để làm điều này, đặc biệt là vì một phương pháp bổ sung được chế tạo riêng cho fishmôi trường vỏ.
Có vẻ như nguyên nhân gốc rễ là:
- khởi tạo RVM nhiều lần, bởi vì tôi có nhiều câu lệnh, một câu lệnh cho mỗi tệp cấu hình thiết bị đầu cuối và vì cách chúng bị xiềng xích, tôi không biết những câu lệnh khác được thêm tự động.
- Hoặc, bằng cách nào đó, các câu lệnh đã được thêm vào, trộn lẫn việc khởi tạo cho một môi trường đầu cuối, giả sử
fish, và đang được chạy trong môi trường đầu cuối khác của tôi bash, hoặc ngược lại. Điều này có thể được nhìn thấy trong các chi tiết của tôi bên dưới, nơi bashPATH bị hỏng có một số đường dẫn được phân tách bằng :s, nhưng sau đó các đường dẫn khác cũng được bao gồm bởi khoảng trắng, đó là cú pháp không chính xác bash, nhưng chính xác cho fish.
- Hoặc cả hai đã xảy ra!
Sau đó, một phần khác của vấn đề gốc là dường như có một lỗi liên quan đến RVM / direnv xuất hiện gần đây liên quan đến chức năng bẫy. Tôi có thể gặp lại điều này một lần nữa bằng cách có một trong những bản phát hành RVM có vấn đề khác có thể gây ra bởi:
- Cài đặt lại:
curl -sSL https://get.rvm.io | bash
- Cập nhật thủ công:
rvm get head
- Một bản cập nhật tự động (mà tôi vừa thực hiện) bằng cách thêm
rvm_autoupdate_flag=2vào~/.rvmrc
Vấn đề này cần được khắc phục kể từ ngày 30 tháng 3 năm 2016 hoặc phát hành 1.26.11:
Câu chuyện
Sau khi chiến đấu với các tiện ích GNU để thực hiện tìm kiếm hoàn chỉnh hệ thống tệp, nhìn trộm nội dung tệp, tôi đã sử dụng Atom để thực hiện điều này để thành công hơn và thấy rằng sự xuất hiện duy nhất shell_session_updateđược tìm thấy trong /etc/bashrc_Apple_Terminaltệp được đề cập bởi Zanchey (bên cạnh các tệp lịch sử và như vậy). Tôi cũng không chắc tại sao nó lại được chạy bởi vì tôi đang sử dụng iTerm (2), và giá trị của $TERM_PROGRAMtrong trường hợp đó là iTerm.appkhông Apple_Terminal.
Vì một số lý do, điều đó cũng không giúp tôi, vì đã phải quản lý cài đặt RVM hơn một lần, trải qua quá trình cài đặt, dường như đã thêm cấu hình cho một số 'dotfiles', trong đó tôi cũng đã thêm một số dòng hoặc thủ công .
Cùng với đó tôi đã tạo một .bashrctệp và liên kết với nó từ .bash_profilemáy Mac của tôi, vì nó dường như không tồn tại theo mặc định. Trước đây tôi đã đọc trên một hệ thống Linux, theo quy ước, .bash_profiletốt cho một số tùy chỉnh và .bashrctốt cho các hệ thống khác như xác định bí danh và chức năng của người dùng hoặc ngược lại. Vì vậy, tôi không quen nhìn vào bên trong .bash_profiletệp, và đặc biệt không phải là .profiletệp, tất cả trong thư mục người dùng, hệ thống tương tự cũng sao chép. Chúng ta cũng đừng quên một path_helperhỗn hợp (!), Nhưng dường như không đóng góp cho bất kỳ vấn đề nào.
Các cách có thể để thiết lập môi trường, có thể đúng hoặc không, như sau:
Thêm chi tiết
Để có độ dài đáng kinh ngạc hơn, đây là một số đường dẫn ví dụ mà tôi đã thu được giữa các môi trường khác nhau trong khi gỡ lỗi vấn đề:
Cá ban đầu (bị hỏng)
/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/ thùng
Cá tự nhiên tốt hơn
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
Bash gốc (bị hỏng)
/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
'Thủ công bash PATH cố định
/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
'Đương nhiên' tốt hơn bash 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
Ghi chú:
- 'Bản gốc là từ việc bắt đầu môi trường hoàn toàn mới trong trình thông dịch dòng lệnh trong khi gặp sự cố.
- 'Hướng dẫn' tất nhiên là khi tôi lấy chuỗi đường dẫn không chính xác, sửa lỗi cú pháp và thấy trình thông dịch hoạt động đúng hơn, vì vậy tôi biết những gì sẽ xảy ra khi tiếp tục khắc phục nguyên nhân gốc.
- 'Tự nhiên là từ lần đầu tiên tôi bỏ qua việc tải các tệp cấu hình môi trường đầu cuối của mình
.bashrc, v.v., và cuối cùng chúng đã chạy sau khi vấn đề được giải quyết.
shell_session_updatelà một hàm Bash được cài đặt bởi OS X/etc/bashrc_Apple_Terminal, do đó, có lẽ một cái gì đó trong các lệnh Bash mà RVM chạy đang tạo ra nó như là đầu ra.