Pregunta Elegir entre .bashrc, .profile, .bash_profile, etc. [duplicar]


Esta pregunta ya tiene una respuesta aquí:

Esto es vergonzoso, pero después de muchos años de usar sistemas POSIX a tiempo completo, todavía me cuesta entender si una personalización de shell debe ir en .bashrc, .profile, o en otra parte. 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 se carga o no cada archivo. Lo que me pregunto es si alguien ha reunido todas las pautas completas sobre cómo decidir qué archivo incluir en un determinado tipo de personalización.


169


origen


esta pregunta no debe marcarse como duplicada, la razón es .profile no está disponible en la pregunta agregada. - Premraj
Ans: serverfault.com/q/261802/270464 - Premraj


Respuestas:


TL; DR:

  • ~/.bash_profile debería ser súper simple y solo cargar .profile y .bashrc (en ese orden)

  • ~/.profile tiene las cosas NO específicamente relacionado con bash, como las variables de entorno (PATH y amigos)

  • ~/.bashrc tiene todo lo que quieras en una línea de comando interactiva. Símbolo del sistema, EDITOR variable, alias 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

  • ~/.bashrc no debe dar salida a nada

  • Todo lo que debería estar disponible solo para iniciar sesión debe ir ~/.profile

  • Asegurarse de que ~/.bash_login no existe.


190



+1, esto permite ~/.profile configurar correctamente el entorno para servicios como GDM / LightDM / LXDM que ejecutan explícitamente / bin / sh. - grawity
Mi .bashrc produce un montón de cosas, ¿puedes comentar sobre eso? En particular, ¿dónde debería colocar la salida de saludo? - Calimo
@Calimo: Haga que solo salga material en modo interactivo. Puedes probarlo usando [[ $- == *i* ]], es decir, buscando 'yo' en el especial $- variable. Por supuesto, solo importa en primer lugar en sistemas donde bash está compilado para leer .bashrc en modo no interactivo. (Es decir, Debian pero no Arch.) Pero es una causa frecuente de misteriosos mensajes de error al intentar conectarse usando sftp o scp o herramientas similares. - grawity
Ahora tengo que saber, ¿por qué no debería existir .bash_login? ¿Qué hace? - tedder42
@ tedder42: Hace lo mismo que .bash_profile y .profile. Pero bash solo lee el primero de tres. Es decir, si tienes un .bash_login, entonces ambos .profile y .bash_profile será misteriosamente ignorado. - grawity


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

Los requisitos:

  • ~/.profile debe ser compatible con cualquier / bin / sh; esto incluye bash, dash, ksh, cualquier otra cosa que una distribución pueda elegir usar.

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

  • No tiene mucho sentido tener ambos  ~/.profile y ~/.bash_profile. Si falta este último, bash utilizará felizmente el anterior, y cualquier línea específica de bash puede ser protegida con un control de $BASH o $BASH_VERSION.

  • La separación entre *profile y *rc es que el primero se usa para los shells de "inicio de sesión" y el último cada vez que se abre una ventana de terminal. Sin embargo, bash en el modo de "inicio de sesión" no es fuente ~/.bashrc, por lo tanto ~/.profile necesita hacerlo manualmente

los más simple configuración sería:

  • Tener un ~/.profile que establece todas las variables de entorno (excepto las específicas de bash), tal vez imprime una línea o dos, luego las fuentes ~/.bashrc si es ejecutado por bash, pegándose a la sintaxis compatible con sh de lo contrario.

    exportar TZ = "Europa / París"
    export EDITOR = "vim"
    if ["$ BASH"]; entonces
        . ~ / .bashrc
    fi
    tiempo de actividad
    
  • Tener un ~/.bashrc que realiza cualquier configuración específica del shell, protegida con un control de modo interactivo para evitar romper cosas como sftp en Debian (donde bash está compilado con la opción de cargar ~/.bashrcincluso para shells no interactivos):

    [[$ - == * i *]] || return 0
    
    PS1 = '\ h \ w \ $'
    
    start () {sudo service "$ 1" start; }
    

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

  • Ciertas distribuciones (por ejemplo, Debian) compilan su bash con la opción de fuente ~/.bashrc para tales inicios de sesión no interactivos. En este caso, me pareció útil mover todas las variables de entorno (el export ... líneas) a un archivo separado, ~/.environy para obtenerlo de ambos  .profile y .bashrc, con un guardia para evitar hacerlo dos veces:

    Si ! ["$ PREFIX"]; entonces # o $ EDITOR, o $ TZ, o ...
        . ~ / .environ # generalmente cualquier variable que el .environ mismo establecería
    fi
    
  • Desafortunadamente, para otras distribuciones (por ejemplo, Arch), no he encontrado una solución muy buena. Una posibilidad es utilizar el (habilitado por defecto) módulo pam_env PAM, poniendo lo siguiente en ~/.pam_environment:

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

    Entonces, por supuesto, actualizando ~/.environ a unset BASH_ENV.


¿Conclusión? Las conchas son un dolor. Las variables de entorno son un dolor. Las opciones de tiempo de compilación específicas de la distribución son inmenso joda.


45



+1 para el último párrafo, pero prefiero el abastecimiento .profile y .bashrc de .bash_profile y manteniendo .profile limpiar. - nyuszika7h
@ nyuszika7h: Mi .profile  esta limpio, Gracias. - grawity
Tenga en cuenta que el comentario cada vez que abre una ventana es al revés para OSX - Mark
"No tiene mucho sentido tener ambos ~/.profile y ~/.bash_profile": No estoy de acuerdo. Consulte la respuesta de Dan para saber por qué. - rubenvb
@rubenvb ¿Puedes citar la parte relevante? Creo que está bien tener solo un .profile y guarda el bashpartes específicas con condicionales. - Kelvin


Echa un vistazo a esto excelente publicación de blog por ShreevatsaR. Aquí hay un extracto, pero ve a la entrada 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. Lee la columna apropiada. Ejecuta A, luego B, luego C, etc. El B1, B2, B3 significa que ejecuta solo el primero de esos archivos encontrados.

+----------------+-----------+-----------+------+
|                |Interactive|Interactive|Script|
|                |login      |non-login  |      |
+----------------+-----------+-----------+------+
|/etc/profile    |   A       |           |      |
+----------------+-----------+-----------+------+
|/etc/bash.bashrc|           |    A      |      |
+----------------+-----------+-----------+------+
|~/.bashrc       |           |    B      |      |
+----------------+-----------+-----------+------+
|~/.bash_profile |   B1      |           |      |
+----------------+-----------+-----------+------+
|~/.bash_login   |   B2      |           |      |
+----------------+-----------+-----------+------+
|~/.profile      |   B3      |           |      |
+----------------+-----------+-----------+------+
|BASH_ENV        |           |           |  A   |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|                |           |           |      |
+----------------+-----------+-----------+------+
|~/.bash_logout  |    C      |           |      |
+----------------+-----------+-----------+------+

29



Esto es bonito. Es importante tener en cuenta que generalmente /etc/profile llamadas /etc/bash.bashrcy ~/.profile llamadas ~.bashrc. De manera efectiva /etc/bash.bashrc y ~/.bashrc se están ejecutando para inicios de sesión interactivos también. - wisbucky
Tenga en cuenta que algunas distribuciones parecen anular este esquema (con consecuencias extrañas); consulte p. Ej. mi informe de error para opensuse aquí: bugzilla.opensuse.org/show_bug.cgi?id=1078124 - Christian Herenz


Te ofrezco mis pautas "integrales":

  • Hacer .bash_profile y .profile carga .bashrc si existe, usando, por ejemplo, [ -r $HOME/.bashrc ] && source $HOME/.bashrc
  • Pon todo lo demás en .bashrc.
  • Deja de preocuparte.
  • Cada cuatro años más o menos, dedique diez minutos a investigar esta misma pregunta antes de darse por vencido y volver a "no preocuparse".

EDITAR: Agregó citas de susto a "exhaustivo" en caso de que alguien esté tentado de creerlo. ;)


19



Tener ambos .bash_profile y .profile es un poco redundante; solo necesitas lo último. Sin embargo, necesitas hacerlo / bin / sh-proof: if [ "$BASH" ] && [ -r ~/.bashrc ]; then . ~/.bashrc; fi, ya que hay programas (a saber, gdm / lightdm) que manualmente originan el archivo desde un script / bin / sh. Esto también significa que el ambiente se mantuvo .bashrc sería ineficaz Tuvo que ir a -1, ya que sus pautas "integrales" no funcionarán en muchos sistemas, ya que me he enterado por las malas varias veces. - grawity
No hay problema, felizmente pagaría un -1 por una respuesta que no es meramente irónica "integral", y ciertamente te has ganado ese título. - Mechanical Fish


Dejé de intentar resolver esto e hice un guión (~/.shell-setup) que fuente de todos los demás.

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

  1. Solo ejecute una vez, incluso cuando proceda varias veces (use Incluye guardias)
  2. No generes ninguna salida no deseada (detecta cuando la salida está bien)

# 1 es bastante estándar, aunque tal vez no se usa mucho en scripts de shell.

# 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 o por qué detectar un shell interactivo no fue suficiente


0





Pon todo en .bashrc y luego fuente .bashrc de .profile

Desde la página bash man (en OS X 10.9):

Cuando se inicia un shell interactivo que no es un shell de inicio de sesión, bash lee y ejecuta comandos desde ~ / .bashrc, si ese archivo existe. Esto puede inhibirse al usar la opción --norc. La opción del archivo --rcfile obligará a bash a leer y ejecutar comandos desde el archivo en lugar de ~ / .bashrc

El texto anterior es por qué todo se pone en .bashrc. Sin embargo, hay un comportamiento un poco diferente cuando se trata de un shell de inicio de sesión. Nuevamente, citando de la página man:

Cuando bash se invoca como un shell de inicio de sesión interactivo o como un shell no interactivo con la opción --login, primero lee y ejecuta comandos desde el archivo / etc / profile, si ese archivo existe. Después de leer ese archivo, busca ~ / .bash_profile, ~ / .bash_login, y ~ / .profile, en ese orden, y lee y ejecuta comandos del primero que existe y que es legible. La opción --noprofile se puede usar cuando el shell se inicia para inhibir este comportamiento.

.profile se lee para shells de inicio de sesión, pero .bashrc no es. Duplicando todas esas cosas en .bashrc es malo, así que tenemos que buscarlo en .profile para que el comportamiento permanezca constante.

Sin embargo, no quieres fuente .bashrc de .profile incondicionalmente Por favor, consulte los comentarios y otras respuestas para obtener detalles adicionales.


-1



-1, NO HAGA fuente .bashrc de .profile. Ver la respuesta de @ DanRabinowitz. - nyuszika7h
Al menos no incondicionalmente - nyuszika7h
[ -n "$BASH" -a -f ~/.bashrc ] && . ~/.bashrc sería un dulce delineador de .profile. - John WH Smith
@ nyuszika7h, ¿por qué no? Todo el mundo parece sugerir hacerlo. - Pacerier