¿Variables de entorno en bash_profile o bashrc?

Apr 05 2012

He encontrado esta pregunta [blog]: La diferencia entre .bashrc y .bash_profile es muy útil, pero después de ver la respuesta más votada (muy buena por cierto) tengo más preguntas. Hacia el final de la respuesta correcta más votada, veo la declaración de la siguiente manera:

Tenga en cuenta que puede ver aquí y allá recomendaciones para poner definiciones de variables de entorno en ~ / .bashrc o siempre lanzar shells de inicio de sesión en terminales. Ambas son malas ideas.

¿Por qué es una mala idea (no estoy tratando de pelear, solo quiero entender)?
Si quiero establecer una variable de entorno y agregarla a la RUTA (por ejemplo, JAVA_HOME), ¿dónde sería el mejor lugar para colocar la entrada de exportación? en ~ / .bash_profile o ~ / .bashrc ?
Si la respuesta a la pregunta número 2 es ~ / .bash_profile , entonces tengo dos preguntas más:

3.1. ¿Qué pondrías debajo de ~ / .bashrc ? solo alias?

3.2. En un shell sin inicio de sesión, creo que ~ / .bash_profile no se está "recogiendo". Si la exportación de la entrada JAVA_HOME estuviera en bash_profile, ¿podría ejecutar los comandos javac y java ? ¿Los encontraría en el PATH? ¿Es esa la razón por la que algunas publicaciones y foros sugieren configurar JAVA_HOME y similares en ~ / .bashrc ?

Gracias por adelantado.

Respuestas

28 geekosaur Apr 06 2012 at 04:36

En un sistema moderno no es especialmente común encontrarse con los casos en los que importa, pero sucede. (En particular, si usa operaciones de shell vimcomo :r !commando en el !<motion>commandformulario en línea ).

¿Qué pondrías debajo de ~ / .bashrc? solo alias?

Pones cosas ~/.bashrcque no serían heredadas automáticamente por las subcapas; esto significa alias y funciones, en su mayoría, aunque a veces tiene configuraciones variables que no desea que estén visibles fuera del shell (esto es muy raro). Se podría argumentar que deberían exportarse de alguna manera, pero varios intentos experimentales se han encontrado con problemas de compatibilidad al intentar ocultarlos en el entorno y, en su mayoría, se han abandonado.

Si quiero establecer una variable de entorno y agregarla a la RUTA (por ejemplo, JAVA_HOME), ¿dónde sería el mejor lugar para colocar la entrada de exportación? en ~ / .bash_profile o ~ / .bashrc?

Pones la configuración del entorno de ~/.bash_profilemodo que se les dé una configuración inicial sana. A veces querrá anularlos (a menudo esto se hace en entornos complejos como Matlab o Cadence); Si coloca la configuración del entorno ~/.bashrc, los shells que se ejecutan desde esos entornos perderán las personalizaciones de los entornos y, como resultado, es posible que las cosas no funcionen correctamente. Esto también se aplica si usa un paquete como módulos , virtualenv , rvm , etc. para administrar múltiples entornos de desarrollo; poner su configuración ~/.bashrcsignifica que no puede ejecutar el entorno que desea desde su editor, sino que se verá obligado a ingresar al sistema predeterminado.

En un shell sin inicio de sesión, creo que ~ / .bash_profile no se está "recogiendo".

Esto es correcto; normalmente desea que el shell inicial sea un shell de inicio de sesión y cualquier shell que se inicie debajo de ese no sea un shell de inicio de sesión. Si el shell inicial no es un shell de inicio de sesión, no tendrá una configuración predeterminada PATHni otras configuraciones (incluido su JAVA_HOMEejemplo).

La mayoría de los entornos de escritorio iniciados desde administradores de pantalla (es decir, la gran mayoría de inicios de sesión gráficos) no configuran un entorno de inicio de sesión para todo el escritorio, por lo que se ve obligado a ejecutar el shell inicial en terminales como un shell de inicio de sesión. Esto causa una serie de problemas (en particular, que los PATHprogramas disponibles para los programas que se ejecutan desde, por ejemplo, paneles no están configurados correctamente, porque el panel no es un terminal y no se ha ejecutado ~/.bash_profile), pero es un compromiso razonable dado que no siempre es posible para ejecutarse sensatamente ~/.bash_profileen el entorno no interactivo al comienzo de una sesión iniciada por un administrador de pantalla, dependiendo de su contenido. A veces se sugiere colocar la configuración del entorno en ~/.bashrclugar de configurar un shell de inicio de sesión; como se mencionó anteriormente, esto funciona siempre que no necesite anular ese entorno y cause roturas extrañas una vez que lo necesite.

Hace poco ayudé a diagnosticar un problema como este en OS X donde un usuario que había colocado la configuración y ~/.bashrcluego comenzó a usar rvmy perlbrew vio un comportamiento extraño, porque los entornos configurados por los dos fueron "deshechos" por los ~/.bashrceditores internos y sudo(que en OS X , a diferencia de Linux, propaga el usuario $HOMEpara que ~/.bashrclo ejecute el shell raíz). Antes de intentar utilizar esos entornos, no hubo ningún problema; al empezar a utilizarlos, quedaron desconcertados por la inesperada pérdida de su configuración.

2 bubu Apr 06 2012 at 04:28

para ser honesto, hay poca diferencia en estos días a pesar de lo que dijo el gurú.

El problema detrás de esto es que hoy en día iniciamos sesión gráficamente en lugar de a través de un shell de inicio de sesión. En el pasado, a los usuarios de Unix nos gusta ver un breve informe de lo que está sucediendo en un servidor inmediatamente después de iniciar sesión; luego comenzaremos X por línea de comando; estos informes a menudo requieren algo de tiempo para generarse (por ejemplo, 10-20 segundos). y luego no queremos ver lo mismo cuando comenzamos, por ejemplo, xterm. de ahí la diferencia.

hoy en día no creo que la distinción sea importante ahora. Creo que en estos días, si obtiene bashrc en bash_profile, nadie podría culparlo.

tenga en cuenta que esto no se aplica a macos x (cada terminal.app iniciada es un shell de inicio de sesión)

1 hute37 Nov 20 2015 at 10:14

Bueno, sobre los "inicios de sesión gráficos", depende de qué * DM utilice ...

Con GDM (Gnome 3.18) tengo esto:

/ etc / gdm / Xsession

#!/bin/sh   <= *important*

...

# First read /etc/profile and .profile
test -f /etc/profile && . /etc/profile
test -f "$HOME/.profile" && . "$HOME/.profile"
# Second read /etc/xprofile and .xprofile for X specific setup
test -f /etc/xprofile && . /etc/xprofile
test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

Entonces, ~ / .profile se obtiene en el inicio de sesión usando / bin / sh y no / bin / bash

Hay dos casos

/ bin / sh está vinculado a / bin / bash pero se ejecuta en modo "POSIX / Bourne"
/ bin / sh es / bin / dash (debian / ubuntu). Más rápido pero con menos funciones (compatibilidad con ShellShock;) )

Entonces el perfil / bin / sh es ~ / .profile y no ~ / .bash_profile, ~ / .zprofile

Este archivo debe usarse para configuraciones "independientes del shell" , como la ruta y las variables de entorno.

NINGÚN programa ejecutable para la interacción del usuario solo para iniciar sesión debería estar aquí (verificación de correo, fortuna, etc.)

los ~ /.* rc están pensados solo para sesiones "interactivas" (alias, por ejemplo ...)

Existe una diferencia entre bash y zsh para los shells de inicio de sesión interactivos

bash solo fuentes .bash_profile, mientras que zsh fuentes en el orden:

~ / .zprofile
~ / .zshrc
~ / zlogin (aquí los alias definidos en ~ / .zshrc están disponibles. en caso de shells "interactivos" + "login"

La forma correcta de hacerlo ~ / .bash_profile se respondió aquí:

Diferencia entre .bashrc y .bash_profile

if [ -r ~/.profile ]; then . ~/.profile; fi
case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

Para habilitar la prueba (y la creación de perfiles), puede utilizar este

~ / .bash_profile:

#!/bin/bash

# ------------------------------------------------
export _DOT_BASH_PROFILE_0=`date  --rfc-3339=ns`
# ------------------------------------------------

if [ -f ~/.profile ] ; then
    . ~/.profile
fi

case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

# ------------------------------------------------
export _DOT_BASH_PROFILE_1=`date  --rfc-3339=ns`
# ------------------------------------------------

~ / .zprofile:

#!/bin/zsh

# ------------------------------------------------
export _DOT_ZSH_PROFILE_0=`date  --rfc-3339=ns`
# ------------------------------------------------

if [ -f ~/.profile ] ; then
    . ~/.profile
fi

# no need to source, zsh already handle ~/.zshrc

###case "$-" in *i*) if [ -r ~/.zshrc ]; then . ~/.zshrc; fi;; esac

# ------------------------------------------------
export _DOT_ZSH_PROFILE_1=`date  --rfc-3339=ns`
# ------------------------------------------------

luego, para probar:

chsh -s /bin/bash

ssh localhost
env

exit

ssh localhost env

ssh -t localhost bash -i -c env


chsh -s /bin/zsh

ssh localhost
env

exit

ssh localhost env

ssh -t localhost bash -i -c env

Entonces RVM / virtualenv debería ir en ~ / .profile, en mi humilde opinión

Pero esto NO FUNCIONA , a veces ...

Por ejemplo, virualenvwrapper solo funciona si el shell que ejecuta Xsession es un bash "original" (exportando BASH_VERSION)

Si está en un sistema de tablero , la variable de entorno y la configuración de la ruta funcionan, pero la definición de la función virualenvwrapper no funciona porque el script no es compatible con POSIX.

El script no da ningún error pero termina sin ninguna definición de "trabajo" .

Por lo tanto, puede configurar el entorno en ~ / .profile , solo para habilitar la ejecución correcta de Python desde el cliente iniciado directamente desde X: