¿Por qué la fuente predeterminada ~ / .profile de Ubuntu ~ / .bashrc?

Estos son los contenidos del stock ~/.profileque vino con mi 13.10 (líneas comentadas eliminadas):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Esto se hereda de Debian, pero ¿por qué Canonical decidió conservarlo? Hasta donde sé, no es la forma estándar * nix y he visto varios sistemas en los que esto no sucedió, por lo que supongo que deben haber tenido una buena razón para hacerlo. Esto puede causar un comportamiento inesperado cuando se ejecutan shells de inicio de sesión (por ejemplo, cuando se sshing en la máquina) donde el usuario no esperaría haber ~/.bashrcoriginado.

El único beneficio que se me ocurre es no confundir al usuario con muchos archivos de inicio y permitirle editar .bashrcsolo y tener esa lectura independientemente del tipo de shell. Sin embargo, eso es un beneficio dudoso, ya que a menudo es útil tener diferentes configuraciones para iniciar sesión y para shells interactivos y esto le impide hacerlo. Además, los shells de inicio de sesión a menudo no se ejecutan en un entorno gráfico y eso puede causar errores, advertencias y problemas (¡oh, Dios mío!) Dependiendo de lo que haya configurado en esos archivos.

Entonces, ¿por qué Ubuntu hace esto? ¿Qué me estoy perdiendo?

Esta es una decisión previa proveniente de Debian. La razón para ello se explica en esta muy bonita publicación wiki , de la cual lo siguiente es un extracto. El resumen ejecutivo es "para garantizar que los inicios de sesión GUI y no GUI funcionen de la misma manera":

Tomemos xdm como ejemplo. Pierre regresa de vacaciones un día y descubre que su administrador del sistema ha instalado xdm en el sistema Debian. Inicia sesión muy bien, y xdm lee su archivo .xsession y ejecuta fluxbox. ¡Todo parece estar bien hasta que recibe un mensaje de error en la ubicación incorrecta! Como anula la variable LANG en su .bash_profile, y dado que xdm nunca lee .bash_profile, su variable LANG ahora está establecida en en_US en lugar de fr_CA.

Ahora, la solución ingenua a este problema es que en lugar de iniciar "xterm", podría configurar su administrador de ventanas para iniciar "xterm -ls". Este indicador le dice a xterm que, en lugar de iniciar un shell normal, debería iniciar un shell de inicio de sesión. Bajo esta configuración, xterm genera / bin / bash pero pone "- / bin / bash" (o tal vez "-bash") en el vector de argumento, por lo que bash actúa como un shell de inicio de sesión. Esto significa que cada vez que abre un nuevo xterm, leerá / etc / profile y .bash_profile (comportamiento de bash incorporado), y luego .bashrc (porque .bash_profile dice hacer eso). Puede parecer que esto funciona bien al principio: sus archivos de puntos no son pesados, por lo que ni siquiera nota el retraso, pero hay un problema más sutil. También lanza un navegador web directamente desde su menú de fluxbox, y el navegador web hereda la variable LANG de fluxbox, que ahora está configurada en la configuración regional incorrecta. Entonces, aunque sus xterms pueden estar bien, y cualquier cosa lanzada desde sus xterms puede estar bien, su navegador web todavía le está dando páginas en la ubicación incorrecta.

Entonces, ¿cuál es la mejor solución para este problema? Realmente no hay uno universal. Un mejor enfoque es modificar el archivo .xsession para que se vea así:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

Esto hace que el shell que interpreta el script .xsession lea en / etc / profile y .bash_profile si existen y son legibles, antes de ejecutar xmodmap o xterm o "ejecutar" el administrador de ventanas. Sin embargo, hay un inconveniente potencial para este enfoque: bajo xdm, el shell que lee .xsession se ejecuta sin un terminal de control. Si / etc / profile o .bash_profile usa algún comando que asume la presencia de un terminal (como "fortune" o "stty"), esos comandos pueden fallar. Esta es la razón principal por la cual xdm no lee esos archivos por defecto. Si va a utilizar este enfoque, debe asegurarse de que todos los comandos en sus "archivos de puntos" sean seguros de ejecutar cuando no haya terminal.

Este es el comportamiento estándar de Ubuntu, ~/.bashrces un archivo de inicio de nivel de usuario por shell interactivo. Cuando abre un terminal, básicamente inicia un shell interactivo sin inicio de sesión que lee ~/.bashrcy el contenido ~/.bashrcse obtiene y exporta a su entorno de shell actual. Ayuda a uno a obtener todas sus variables y funciones de shell definidas por el usuario en el shell actual. También puedes encontrar líneas como esta

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

para obtener alias definidos por el usuario en el entorno actual del shell.

Esto es importante para proporcionar una buena experiencia de usuario también. Por ejemplo, uno podría almacenar en la credencial de proxy .bashrc, a menos que conseguir ninguna de las aplicaciones del terminal de origen ( es decir , ping, wget, curl, lynxetc.) funcionará correctamente. O debe proporcionar las credenciales de proxy cada vez que abra un terminal.

Además, el valor predeterminado de Ubuntu .bashrccontiene muchos alias fáciles de usar (para lse grepimprimir resultados coloreados), muchas definiciones nuevas para diferentes variables de shell que aumenta la experiencia del usuario.

Pero en el caso de su inicio de sesión ssh , o inicio de sesión en la consola virtual , básicamente obtiene un shell de inicio de sesión interactivo. Allí está el archivo de inicio de shell ~/.profile. Por lo tanto, a menos que fuente ~/.bashrcse olvida de todos esos parámetros interesantes en tu .bashrc. Es por eso que la ~/.profilefuente predeterminada de Ubuntu~/.bashrc

Caso para evitar

• nunca debe obtener el ~/.profileformulario ~/.bashrcen el interior al mismo tiempo cuando ~/.bashrcse obtiene ~/.profile. Creará un bucle infinito de situación y, como resultado, su solicitud de terminal se suspenderá a menos que presione Ctrl+ C. En tal situación si pones una línea en tu~/.bashrc

set -x

Entonces podría ver que el descriptor de archivo se detiene cuando abre un terminal.