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

Pregunta:

Estoy leyendo acerca de las secuencias de comandos de shell básicas de la línea de comandos de Linux y la Biblia de secuencias de comandos de Shell .

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

  • ¿Por qué estos archivos no forman parte de /etc/profile si también son fundamentales 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 que contienen configuraciones?

Respuesta:

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

Si te refieres a "¿Por qué no se combinan en un solo guión gigante?", La respuesta es:

  1. Porque eso sería una pesadilla de mantenimiento para las personas responsables de los scripts.
  2. Debido a que tener los scripts cargados como módulos independientes hace que todo el sistema sea más ajustable dinámicamente, se pueden agregar y eliminar scripts individuales sin afectar a los demás. Etc.
  3. Porque se cargan a través de / etc / profile, lo que los convierte en parte del "perfil" de bash 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 que contienen configuraciones?

Me parece una cuestión de filosofía de diseño más amplia que dividiré en dos. La primera pregunta es sobre el valor y la conveniencia de utilizar el entorno de shell. ¿Tiene valor positivo? Sí, 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 es ampliamente reconocido y comprendido. Por el contrario, al decidir configurar tales cosas de forma 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, las cosas de $ LC lang podrían estar en un archivo de texto con un formato personalizado en otro lugar, etc., ¿no parece más simple el uso de variables env y /etc/profile.d repente? Probablemente ya sepa qué es una variable env, cómo funcionan y cómo usarlas, 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 usarse, etc.). Pero:

  • Siendo realistas, no son tantos datos, en parte porque nadie en su sano juicio lo usaría para más de unos pocos parámetros simples (ya que existen 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 por defecto desde un archivo en algún lugar cada vez que invoque gcc serí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ían agregar más a esa lista, pero es de esperar que esto le dé una idea de los pros y los contras del problema: el principal 'pro' y el principal 'contra' es que se trata de un espacio de nombres global.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım