TL; DR: Asegúrese de que RVM esté actualizado al menos a 1.26.11 reinstalando o emitiendo el comando rvm get head, y solo se esté inicializando una vez por entorno de terminal.
Resultado
Finalmente pude arreglar mi entorno. Publicaré información relacionada con mi problema específico en un esfuerzo por ayudar a algunos, aunque otros puedan tener el mismo síntoma pero otra causa raíz.
Porque
Una parte del problema raíz provenía de RVM, y cómo se estaba inicializando para mis entornos de línea de comandos. Encontré un par de formas diferentes de hacer esto, especialmente porque un método adicional fue diseñado específicamente para el fishentorno de shell.
Parece que la causa raíz fue:
- Inicializando RVM más de una vez, porque tenía varias instrucciones, una por archivo de configuración de terminal, y debido a cómo estaban encadenadas, no estaba al tanto de las otras que se agregaban automáticamente.
- O, de alguna manera, se agregaron declaraciones que mezclaban la inicialización para un entorno de terminal, por ejemplo
fish, y se ejecutaban en mi otro entorno de terminal bash, o viceversa. Esto se puede ver en mis detalles a continuación, donde la bashRUTA rota tiene algunas de las rutas delimitadas por :s, pero luego otras también están incluidas por espacios, que es una sintaxis incorrecta bash, pero correcta fish.
- ¡O ambas estaban sucediendo!
Luego, la otra parte del problema raíz fue que parece que recientemente se produjo un error relacionado con RVM / direnv con respecto a la función trap. Probablemente encontré esto nuevamente al tener una de las otras versiones problemáticas de RVM que podrían ser causadas por:
- Una reinstalación:
curl -sSL https://get.rvm.io | bash
- Una actualización manual:
rvm get head
- Una actualización automática (que acababa de hacer) agregando
rvm_autoupdate_flag=2a~/.rvmrc
Este problema debe solucionarse a partir del 30 de marzo de 2016 o la versión 1.26.11:
La historia
Después de luchar con las utilidades de GNU para hacer una búsqueda completa del sistema de archivos, mirar dentro del contenido del archivo, utilicé Atom para hacer esto con más éxito, y descubrí que la única aparición shell_session_updatese encontró en el /etc/bashrc_Apple_Terminalarchivo mencionado por Zanchey (además de los archivos de historial y tal). Tampoco estoy seguro de por qué se estaba ejecutando porque estaba usando iTerm (2), y el valor de $TERM_PROGRAMen ese caso es iTerm.appy no Apple_Terminal.
Tampoco ayudó que, por alguna razón, tuviera que administrar la instalación de RVM más de una vez, pasando por el proceso de instalación, que aparentemente ya agrega la configuración a varios 'archivos de puntos', donde también había agregado manualmente algunas o las líneas .
Junto con eso, hice un .bashrcarchivo y lo vinculé desde .bash_profilemi Mac, ya que aparentemente no existía por defecto. Anteriormente había leído en un sistema Linux que, por convención, .bash_profilees bueno para algunas personalizaciones, y .bashrces bueno para otros, como la definición de alias de usuario y funciones, o viceversa. Así que no estaba acostumbrado a mirar dentro del .bash_profilearchivo, y especialmente no en el .profilearchivo, todo en el directorio de usuarios, que también copia un sistema similar. Tampoco olvidemos que hay un path_helperen la mezcla (!), Pero no parece contribuir a ningún problema.
Las posibles formas de configurar el entorno, que pueden ser correctas o no, son las siguientes:
Más detalles
Para una verbosidad más increíble, aquí hay algunos caminos de ejemplo que capturé entre diferentes entornos al depurar el problema:
RUTA original (rota) de pescado
/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/ compartimiento
'Naturalmente' mejor pez RUTA
/ usr / local / opt / coreutils / libexec / gnubin / usr / local / opt / findutils / bin / usr / local / bin / usr / bin / bin / usr / sbin / sbin / usr / local / munki
RUTA original (rota)
/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
'Manualmente' fijo bash 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
'Naturalmente' mejor 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
Notas:
- Los 'originales eran de comenzar el nuevo entorno en cualquiera de los intérpretes de línea de comando mientras tenían el problema.
- El 'manual' es, por supuesto, cuando tomé la cadena de ruta incorrecta, arreglé los errores de sintaxis y vi un funcionamiento más adecuado del intérprete, así que supe qué esperar al continuar arreglando la causa raíz.
- Los 'naturales' fueron de cuando omití por primera vez cargar mis archivos de configuración del entorno del terminal,
.bashrcetc., y luego finalmente los ejecuté después de que se resolvió el problema.
shell_session_updatees una función Bash instalada por OS X/etc/bashrc_Apple_Terminal, por lo que presumiblemente algo en los comandos Bash que ejecuta RVM la produce como salida.