TL; DR: assicurarsi che RVM sia aggiornato almeno all'1.26.11 reinstallando o eseguendo il comando rvm get heade che venga inizializzato solo una volta per ambiente terminale.
Risultato
Alla fine sono stato in grado di riparare il mio ambiente. Pubblicherò alcune informazioni relative al mio problema specifico nel tentativo di aiutare alcuni, anche se altri potrebbero avere lo stesso sintomo ma un'altra causa principale.
Causa
Una parte del problema alla radice proveniva da RVM e da come veniva inizializzata per i miei ambienti a riga di comando. Avevo trovato un paio di modi diversi per farlo, soprattutto perché un metodo in più era stato appositamente progettato per l' fishambiente shell.
Sembra che la causa principale sia stata:
- inizializzazione di RVM più di una volta, poiché avevo più istruzioni, una per file di configurazione del terminale e, a causa del modo in cui erano concatenate, non ero a conoscenza delle altre aggiunte automaticamente.
- Oppure, in qualche modo sono state aggiunte dichiarazioni che mescolavano l'inizializzazione per un ambiente terminale, diciamo
fish, e venivano eseguite nell'altro mio ambiente terminale bash, o viceversa. Questo può essere visto nei miei dettagli qui sotto dove il bashPATH rotto ha alcuni dei percorsi delimitati da :s, ma poi altri inclusi anche dagli spazi, che è sintassi errata per bash, ma corretta per fish.
- O stavano accadendo entrambi!
Quindi l'altra parte del problema di root era che sembra che un bug relativo a RVM / direnv si sia insinuato recentemente riguardo alla funzione trap. Probabilmente l'ho riscontrato di nuovo avendo una delle altre versioni problematiche di RVM che potrebbero essere causate da:
- Una reinstallazione:
curl -sSL https://get.rvm.io | bash
- Un aggiornamento manuale:
rvm get head
- Un aggiornamento automatico (che avevo appena fatto) aggiungendo
rvm_autoupdate_flag=2a~/.rvmrc
Questo problema dovrebbe essere risolto il 30 marzo 2016 o la versione 1.26.11:
La storia
Dopo aver combattuto con le utility GNU per fare una ricerca completa del file system, sbirciando all'interno del contenuto del file, ho usato Atom per fare questo con maggior successo, e ho scoperto che l'unica occorrenza di è shell_session_updatestata trovata nel /etc/bashrc_Apple_Terminalfile menzionato da Zanchey (oltre ai file di cronologia e simili). Inoltre non sono sicuro del motivo per cui è stato eseguito perché stavo usando iTerm (2), e il valore di $TERM_PROGRAMin quel caso è iTerm.appe no Apple_Terminal.
Inoltre, non ha aiutato il fatto che, per qualche motivo, ho dovuto gestire l'installazione di RVM più di una volta, attraversando il processo di installazione, che apparentemente aggiunge già la configurazione a diversi 'dotfile', dove avevo anche aggiunto manualmente alcune o le linee .
Insieme a questo avevo creato un .bashrcfile e collegato ad esso dal .bash_profilemio Mac, poiché apparentemente non esisteva per impostazione predefinita. In precedenza avevo letto su un sistema Linux che, per convenzione, .bash_profileè buono per alcune personalizzazioni ed .bashrcè buono per altri come la definizione di alias e funzioni dell'utente o viceversa. Quindi non ero abituato a guardare all'interno del .bash_profilefile, e soprattutto non nel .profilefile, tutto nella directory dell'utente, che copia anche un sistema simile. Non dimentichiamo inoltre che a path_helperè nel mix (!), Ma non sembra contribuire a nessun problema.
I modi possibili per impostare l'ambiente, che possono essere corretti o meno, sono i seguenti:
Più dettagli
Per una verbosità più incredibile, ecco alcuni esempi di percorsi che ho catturato da ambienti diversi durante il debug del problema:
PERCORSO di pesce originale (rotto)
/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/ bidone
PERCORSO di pesce "naturalmente" migliore
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
PERCORSO originale (rotto)
/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
PERCORSO di bash fisso 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
PERCORSO "naturalmente" migliore
/ 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
Gli appunti:
- Gli "originali" erano dovuti all'avvio del nuovo ambiente in entrambi gli interpreti della riga di comando, pur avendo il problema.
- Il 'manuale' è ovviamente quando ho preso la stringa errata del percorso, riparato gli errori di sintassi e visto un funzionamento più corretto dell'interprete, quindi sapevo cosa aspettarmi quando continuavo a correggere la causa principale.
- I "naturali" risalgono a quando ho saltato per la prima volta il caricamento dei file di configurazione del mio ambiente terminale come
.bashrce così via, e poi li ho eseguiti dopo che il problema era stato risolto.
shell_session_updateè una funzione Bash installata da OS X in/etc/bashrc_Apple_Terminal, quindi presumibilmente qualcosa nei comandi Bash che RVM esegue lo sta producendo come output.