TL; DR: verifique se o RVM está atualizado para pelo menos 1.26.11 reinstalando ou emitindo o comando rvm get heade está sendo inicializado apenas uma vez por ambiente de terminal.
Resultado
Eventualmente, consegui consertar meu ambiente. Vou postar algumas informações referentes ao meu problema específico, em um esforço para ajudar alguns, mesmo que outros possam ter o mesmo sintoma, mas outra causa raiz.
Causa
Uma parte do problema raiz vinha do RVM e como ele estava sendo inicializado para meus ambientes de linha de comando. Eu havia encontrado algumas maneiras diferentes de fazer isso, especialmente porque um método extra foi criado especificamente para o fishambiente do shell.
Parece que a causa raiz foi:
- inicializando o RVM mais de uma vez, porque eu tinha várias instruções, uma por arquivo de configuração de terminal, e por causa de como elas foram encadeadas, eu não estava ciente das outras que foram adicionadas automaticamente.
- Ou, de alguma forma, foram adicionadas instruções que misturavam a inicialização de um ambiente de terminal, digamos
fish, e estavam sendo executadas no meu outro ambiente de terminal bash, ou vice-versa. Isso pode ser visto nos meus detalhes abaixo, onde o bashPATH quebrado tem alguns dos caminhos delimitados por :s, mas outros também incluídos por espaços, que é sintaxe incorreta para bash, mas correta para fish.
- Ou ambos estavam acontecendo!
A outra parte do problema raiz é que parece que um bug relacionado ao RVM / direnv surgiu recentemente em relação à função trap. Eu provavelmente encontrei isso novamente por ter um dos outros lançamentos problemáticos do RVM que podem ser causados por:
- Uma reinstalação:
curl -sSL https://get.rvm.io | bash
- Uma atualização manual:
rvm get head
- Uma atualização automática (que acabei de fazer) adicionando
rvm_autoupdate_flag=2ao~/.rvmrc
Esse problema deve ser corrigido em 30 de março de 2016 ou na versão 1.26.11:
A história
Depois de lutar com os utilitários GNU para fazer uma pesquisa completa do sistema de arquivos, espreitando o conteúdo do arquivo, usei o Atom para fazer isso com mais sucesso e descobri que a única ocorrência de shell_session_updatefoi encontrada no /etc/bashrc_Apple_Terminalarquivo mencionado por Zanchey (além dos arquivos de histórico e tal). Também não sei por que isso estava sendo executado porque eu estava usando o iTerm (2), e o valor de $TERM_PROGRAMnesse caso é iTerm.appe não Apple_Terminal.
Também não ajudou que eu, por algum motivo, tivesse que gerenciar a instalação do RVM mais de uma vez, passando pelo processo de instalação, que aparentemente já adiciona configuração a vários 'dotfiles', onde eu também adicionei manualmente algumas ou as linhas .
Junto com isso, eu criei um .bashrcarquivo e vinculei a ele .bash_profileno meu Mac, já que aparentemente não existia por padrão. Eu já havia lido em um sistema Linux que, por convenção, .bash_profileé bom para algumas personalizações e .bashrcpara outros, como definir aliases e funções de usuário ou vice-versa. Portanto, eu não estava acostumado a procurar dentro do .bash_profilearquivo, e especialmente o .profilearquivo, tudo no diretório do usuário, que o sistema semelhante copia também. Também não devemos esquecer que um path_helperestá no mix (!), Mas não pareceu contribuir para nenhum problema.
As maneiras possíveis de configurar o ambiente, que podem estar corretas ou não, são as seguintes:
Mais detalhes
Para uma verbosidade mais incrível, eis alguns exemplos de caminhos que capturei entre diferentes ambientes ao depurar o problema:
CAMINHO (quebrado) de peixe original
/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
'Naturalmente' melhor peixe PATH
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
CAMINHO original (quebrado) do 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
PATH bash fixo 'manualmente'
/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
CAMINHO 'naturalmente' melhor do bash
/ 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
Notas:
- Os 'originais foram desde o início do novo ambiente em um dos intérpretes da linha de comando, enquanto o problema estava ocorrendo.
- O 'manual' é claro quando peguei a cadeia de caminho incorreta, corrigi os erros de sintaxe e vi uma operação mais adequada do intérprete, então sabia o que esperar ao continuar corrigindo a causa raiz.
- O 'natural' era de quando eu pulei o carregamento dos arquivos de configuração do ambiente do terminal, como por exemplo,
.bashrce assim por diante, e depois os executei depois que o problema foi resolvido.
shell_session_updateé uma função Bash instalada pelo OS X in/etc/bashrc_Apple_Terminal, portanto, presumivelmente, algo nos comandos Bash que o RVM executa está produzindo-a como saída.