☰

Elegir entre .bashrc, .profile, .bash_profile, etc.

tag-icon • tag-icon unix environment-variables
Elegir entre .bashrc, .profile, .bash_profile, etc.

Esto es vergonzoso, pero después de muchos años de usar sistemas POSIX a tiempo completo, todavía me resulta difícil determinar si una personalización del shell debería incluirse en .bashrc, .profileo en algún otro lugar. Sin mencionar algunos de los archivos de configuración específicos del sistema operativo como .pam_environment.

Sí, sé cómo descifrar la documentación y saber cuándo está cargado o no cada archivo. Lo que me pregunto es si alguien ha elaborado pautas completas sobre cómo decidir en qué archivo colocar un tipo determinado de personalización.

Respuesta1

TL;DR:

  • ~/.bash_profiledebería ser súper simple y simplemente cargar .profiley .bashrc(en ese orden)

  • ~/.profiletiene cosas que NO están específicamente relacionadas con bash, como variables de entorno ( PATHy amigos)

  • ~/.bashrctiene todo lo que quieras en una línea de comando interactiva. Símbolo del sistema, EDITORvariable, alias de bash para mi uso

Algunas otras notas:

  • Todo lo que debería estar disponible para aplicaciones gráficas O para sh (o bash invocado como sh) DEBE estar en~/.profile

  • ~/.bashrcno debe generar nada

  • Todo lo que debería estar disponible sólo para iniciar sesión en los shells debería ir en~/.profile

  • Asegúrate de que eso ~/.bash_loginno exista.

Respuesta2

En los últimos años he tenido mucho tiempo que perder, así quetenerInvestigué esto durante un poco más de 10 minutos. No tengo idea de si este es el mejor diseño, solo es uno que funciona correctamente en casi todos los casos.

Los requisitos:

  • ~/.profiledebe ser compatible con cualquier /bin/sh – esto incluye bash, dash, ksh, cualquier otra distribución que decida usar.

  • Las variables de entorno deben colocarse en un archivo que sea leído tanto por los inicios de sesión de la consola (es decir, un shell de 'inicio de sesión') como por los inicios de sesión gráficos (es decir, administradores de pantalla como GDM, LightDM o LXDM).

  • Tiene muy poco sentido tenerambos ~/.profiley ~/.bash_profile. Si falta este último, bash usará felizmente el primero, y cualquier línea específica de bash se puede proteger marcando $BASHo $BASH_VERSION.

  • La separación entre *profiley *rces que el primero se usa para shells de 'iniciar sesión' y el segundo cada vez que abre una ventana de terminal. Sin embargo, bash en modo 'iniciar sesión' no genera ~/.bashrc, por lo tanto, ~/.profiledebe hacerlo manualmente.

Ello más simpleconfiguración sería:

  • Tenga un ~/.profileque establezca todas las variables de entorno (excepto las específicas de bash), tal vez imprima una línea o dos, luego las fuentes ~/.bashrcsi se ejecuta mediante bash, de lo contrario, se ciñe a la sintaxis compatible con sh.

    exportar TZ="Europa/París"
exportar EDITOR="vim"
si [ "$BASH" ]; entonces
    . ~/.bashrc
fi
tiempo de actividad

  • Tener un ~/.bashrcque realice cualquier configuración específica de Shell, protegido con una verificación demodo interactivopara evitar romper cosas como sftpen Debian (donde bash se compila con la opción de cargar ~/.bashrcincluso para shells no interactivos):

    [[ $- == *i* ]] || regresar 0

PS1='\h\w\$'

inicio() { sudo servicio "$1" inicio; }

Sin embargo, también existe el problema de que ciertos comandos no interactivos (por ejemplo, ssh <host> ls) se saltan ~/.profile, pero las variables de entorno les serían muy útiles.

  • Ciertas distribuciones (por ejemplo, Debian) compilan su bash con la opción de obtener ~/.bashrcdichos inicios de sesión no interactivos. En este caso, me ha resultado útil mover todas las variables de entorno (las export ...líneas) a un archivo separado ~/.environy obtenerlo deambos .profiley .bashrc, con una guardia para evitar hacerlo dos veces:

    si ! [ "$PREFIJO" ]; entonces   # o $EDITOR, o $TZ, o ...
    . ~/.entorno           # generalmente cualquier variable que el propio .environ establecería
fi

  • Desafortunadamente, para otras distribuciones (por ejemplo, Arch), no he encontrado una solución muy buena. Una posibilidad es utilizar el módulo PAM pam_env (habilitado de forma predeterminada), colocando lo siguiente en ~/.pam_environment:

    BASH_ENV=./.entorno        # no es un error tipográfico; tiene que ser un camino, pero ~ no funcionará

    Luego, por supuesto, actualizar ~/.environa unset BASH_ENV.

¿Conclusión? Las conchas son un fastidio. Las variables ambientales son una molestia. Las opciones de tiempo de compilación específicas de la distribución son unainmensojoda.

Respuesta3

Echa un vistazo a estoexcelente publicación de blog de ShreevatsaR. Aquí hay un extracto, pero vaya a la publicación del blog, incluye una explicación de términos como "shell de inicio de sesión", un diagrama de flujo y una tabla similar para Zsh.

Para Bash, funcionan de la siguiente manera. Lea la columna correspondiente. Ejecuta A, luego B, luego C, etc. B1, B2, B3 significa que ejecuta solo el primero de los archivos encontrados.

Inicio de sesión interactivo Interactivo sin inicio de sesión Guion
/etc/profile A
/etc/bash.bashrc A
~/.bashrc B
~/.bash_profile B1
~/.bash_login B2
~/.profile B3
BASH_ENV A
~/.bash_logout C

Respuesta4

Dejé de intentar resolver esto e hice un script ( ~/.shell-setup) que extraigo de todos los demás.

Este enfoque requiere ~/.shell-setuptener dos características:

  1. Ejecútelo solo una vez, incluso cuando se obtenga repetidamente (useincluir guardias)
  2. No genere ningún resultado no deseado (detecte cuando el resultado sea correcto)

#1 es bastante estándar, aunque quizás no se use mucho en scripts de shell.

El número 2 es más complicado. Esto es lo que uso en bash:

if [ "" == "$BASH_EXECUTION_STRING" -a "" == "$DESKTOP_SESSION" ]; then
    echo "Hello user!" # ... etc
fi

Lamentablemente no recuerdo cómo se me ocurrió eso ni por qué.detectando un shell interactivono fue suficiente.

información relacionada