¿Qué hacen los scripts en /etc/profile.d?

Estoy leyendo sobre las secuencias de comandos de shell básicas de Linux Command Line y Shell Scripting Bible .

Dice que el /etc/profilearchivo establece las variables de entorno al inicio del shell Bash. El /etc/profile.ddirectorio contiene otros scripts que contienen archivos de inicio específicos de la aplicación, que también son ejecutados en el momento del inicio por el shell.

• ¿Por qué estos archivos no forman parte /etc/profilesi también son críticos para el inicio de Bash?

• Si estos archivos son archivos de inicio específicos de la aplicación que no son críticos para el inicio de Bash, ¿por qué forman parte del proceso de inicio? ¿Por qué no se ejecutan solo cuando se ejecutan las aplicaciones específicas, para las cuales contienen configuraciones?

¿Por qué estos archivos no forman parte de / etc / profile si también son críticos para el inicio de Bash?

Si quiere decir, "¿Por qué no se combinan en un guión gigante?", La respuesta es:

1. Porque eso sería una pesadilla de mantenimiento para las personas responsables de los guiones.
2. Debido a que tener los scripts cargados como módulos independientes hace que todo el sistema sea más dinámicamente ajustable: los scripts individuales se pueden agregar y eliminar sin afectar a los demás. Etc.
3. Debido a que se cargan a través de / etc / profile lo que los hace parte del bash "profile" de la misma manera de todos modos.

Si estos archivos son archivos de inicio específicos de la aplicación que no son críticos para el inicio de Bash, ¿por qué forman parte del proceso de inicio? ¿Por qué no se ejecutan solo cuando se ejecutan las aplicaciones específicas, para las cuales contienen configuraciones?

Eso me parece una pregunta de filosofía de diseño más amplia que dividiré en dos. La primera pregunta es sobre el valor y la idoneidad del uso del entorno de shell. ¿Tiene valor positivo? Si, es útil. ¿Es la mejor solución para todos los problemas de configuración? No, pero es muy eficiente para administrar parámetros simples y también ampliamente reconocido y entendido. Compare eso con decir, decidiendo configurar tales cosas de manera heterogénea, tal vez $ PATH podría ser administrado por una herramienta independiente separada, las herramientas preferidas como $ EDITOR podrían estar en un archivo sqlite en algún lugar, $ LC lang podría estar en un archivo de texto con un formato personalizado en otro lugar, etc., no solo usa variables env y/etc/profile.dde repente parece más simple? Probablemente ya sepa qué es una variable env, cómo funcionan y cómo usarla, frente a aprender 5 mecanismos completamente diferentes para 5 aspectos ubicuos diferentes de lo que se denomina apropiadamente "el entorno".

La segunda pregunta es: "¿Es el inicio el momento adecuado para esto?", Lo que plantea la objeción de que no es muy eficiente (todos esos datos que pueden o no ser utilizados, etc.). Pero:

• Siendo realistas, no se trata de tantos datos, en parte porque nadie en su sano juicio lo usaría para más que unos pocos parámetros simples (ya que hay otros medios para configurar una aplicación).
• Si se usa sabiamente, con respecto a las cosas que se invocan comúnmente, entonces establecer, por ejemplo, $ CFLAGS predeterminado desde un archivo en algún lugar cada vez que invoque gccsería menos eficiente. Tenga en cuenta que la cantidad de memoria involucrada es, nuevamente, infinitesimal.
• Puede involucrar cosas sistémicas en las que puede estar involucrada más de una aplicación, y el shell es un terreno común .

Se podría agregar más a esa lista, pero es de esperar que esto le dé alguna idea sobre los pros y los contras del problema: el principal 'pro' y el mayor 'con' es que es un espacio de nombres global.

Esos archivos son específicos de una aplicación, pero se obtienen al iniciar el shell, no cuando se inicia la aplicación. Aquí se usa un directorio de configuración por la misma razón que se encuentra en muchos otros lugares. Esto permite que una aplicación o paquete de software modifique las configuraciones. Esto no sería posible sin una configuración dividida, ya que varios paquetes que intentan administrar / actualizar un solo archivo de configuración que también puede ser modificado por el usuario serían defectuosos y desordenados.

También una nota al margen, /etc/profilese obtiene de todos los shells, no solo bash. El archivo de configuración específico de bash es bashrc y solo se obtiene para shells interactivos.

La respuesta de jordanm es incorrecta. /etc/profileNo se obtiene de todos los depósitos. Como usted señala, no se obtiene mediante csh, tcsh- No estoy seguro acerca de zsh. Se obtiene de los shderivados de Bourne shell ( ), como Korn Shell ( ksh) y BASH ( bash). cshusos /etc/login. Las personas que tienden a usar exclusivamente derivados de Shell Borne tienden a olvidar que existen otros shells. Añaden algo a /etc/profileesperar que se aplique a "todos los usuarios" y luego se sorprenden cuando el usuario extraño de C Shell (y somos un lote extraño) no tiene las cosas en las que se configuró /etc/profile.

Aun así, las personas tienden a olvidarse de que existen otros shells derivados de Borne Shell. Si usan basho ksh, se sienten libres de agregar una sintaxis /etc/profileque no es válida en Bourne Shell, como por ejemplo definir una variable y exportarla en la misma línea. Luego obtienes un script que lo hace #!/bin/shy se ahoga en la sintaxis. /etc/profiledebería ajustarse a la sintaxis compatible con Bourne Shell.

Del mismo modo, debe cumplirlo por su cuenta .profile(use .bash_profilesi desea una sintaxis bash): puede ser un poco más de mecanografía, pero es una mecanografía adicional que hace todo una vez. Referencia ${HOME}y no ~, etc. Algunos tipos de Unix, trabajos cron se ejecutan sh, cada línea suya Makefilees procesada sh, por lo que si está trabajando en varios tipos de UNIX, realmente vale la pena mantener su .profileshell Bourne compatible. Como SysAdmin, no puedo decirte cuántas veces he ayudado a alguien arreglando su .profilecompatibilidad con Bourne Shell.

En Linux, /bin/shes un enlace /bin/bashy, cuando lo ejecuta, se ve la ruta que se utilizó para ejecutarlo y (en teoría) se limita solo a las cosas que admite Bourne Shell. Del mismo modo, vien Linux realmente se vimlimita de nuevo. De vez en cuando ves características "desangrarse". De vez en cuando vimfinge ser viva a hacer algo que vimadmite que vino porque los autores de vimolvidó de desactivar esta en modo "compatibilidad hacia atrás vi". No me sorprendería si bashpretender ser shtiene algunas características similares de "desangrado". No se sorprendería si alguna característica "funciona en Borne Shell en Linux", pero no en un sistema V o UNIX basado en BSD (AIX, OpenBSD, etc.).