¿Qué significa el .d en los nombres de directorio?

Conozco muchos directorios con .d en su nombre:

init.d
yum.repos.d
conf.d

¿Significa directorio? En caso afirmativo, ¿de qué se desambigua esto?

ACTUALIZACIÓN: He tenido muchas respuestas interesantes sobre lo que .dsignifica, pero el título de mi pregunta no fue bien elegido. Cambié "mean" por "stand for".

El .dsufijo aquí significa directorio. Por supuesto, esto sería innecesario, ya que Unix no requiere un sufijo para denotar un tipo de archivo, pero en ese caso específico, algo que era necesario eliminar la ambigüedad de los comandos ( /etc/init, /etc/rc0, /etc/rc1etc.) y los directorios que utilizan ( /etc/init.d, /etc/rc0.d, /etc/rc1.d,. ..)

Esta convención se introdujo al menos con Unix System V pero posiblemente antes. El initcomando solía estar ubicado /etcpero generalmente ahora se encuentra en /sbinlos sistemas operativos modernos de System V.

Tenga en cuenta que esta convención ha sido adoptada por muchas aplicaciones que pasan de un único archivo de configuración de archivo a varios archivos de configuración ubicados en un solo directorio, por ejemplo: /etc/sudoers.d

Una vez más, el objetivo es evitar el choque de nombres, no entre el archivo ejecutable y el archivo de configuración, sino entre el archivo de configuración monolítico anterior y el directorio que los contiene.

Extracto de una lista de correo de Debian (énfasis agregado):

Cuando el empaquetado de distribución se hizo cada vez más común, quedó claro que necesitábamos mejores formas de formar tales archivos de configuración a partir de múltiples fragmentos, a menudo proporcionados por múltiples paquetes independientes. Cada paquete que necesita configurar algún servicio compartido debe poder administrar solo su configuración sin tener que editar un archivo de configuración compartida utilizado por otros paquetes.

La convención más común adoptada fue permitir la inclusión de un directorio lleno de archivos de configuración, donde todo lo que se deja caer en ese directorio se volvería activo y parte de esa configuración. A medida que esa convención se generalizó, ese directorio usualmente recibió el nombre del archivo de configuración que estaba reemplazando o aumentando. Pero dado que uno no puede tener un directorio y un archivo con el mismo nombre, se requirió algún método para distinguir, por lo que .d se agregó al final del nombre del archivo de configuración. Por lo tanto, un archivo de configuración / etc / Muttrc se aumentó mediante fragmentos en /etc/Muttrc.d, / etc / bash_completion se aumentó con /etc/bash_completion.d/*, y así sucesivamente. A veces se utilizan ligeras variaciones en esa convención, como /etc/xinetd.d para complementar /etc/xinetd.conf, o / etc / apache2 / conf. d para complementar /etc/apache2/apache2.conf. Pero es la misma idea básica.

En general, cuando ve esa convención * .d, significa "este es un directorio que contiene un montón de fragmentos de configuración que se fusionarán en la configuración para algún servicio".

Para la parte 2, la razón de la ".d", mi mejor suposición sería "distribuida", ya que no forma parte del archivo de configuración principal, sino que es parte de la configuración .

Si habla de ".d" al final de los nombres de directorio, esta respuesta es correcta, es solo un marcador para "directorio".

Simplemente no lo confunda con "d" en el nombre de un archivo, como "syslogd", que significa daemon . Un proceso informático que se ejecuta en segundo plano.

El proceso padre de un demonio es a menudo (pero no siempre) el proceso init (PID = 1). Los procesos generalmente se convierten en demonios al bifurcar un proceso hijo y luego hacer que su proceso padre salga inmediatamente, lo que hace que init adopte el proceso hijo. Esta es una vista algo simplificada del proceso ya que generalmente se realizan otras operaciones, como la disociación del proceso demonio de cualquier tty de control. Existen rutinas de conveniencia como daemon (3) en algunos sistemas UNIX para ese propósito.

No significa directorio en sí, básicamente lo que está sucediendo es que los directorios que terminan en .d(tenga en cuenta que generalmente solo están en /etc), toman partes de configuración.

Esto está diseñado para que las distribuciones puedan incluir valores predeterminados universales, por ejemplo /etc/yum.conf, pero luego hay un método fácil de usar para que los usuarios u otros paquetes agreguen sus propias configuraciones yum de una manera segura que no se sobrescribirá.

Como ejemplo para mmm ...

Si quisiera comenzar a usar EPEL en mi RHEL5 o CentOS Box, puedo configurar un nuevo repositorio en la /etc/yum.repos.dcarpeta, (digamos /etc/yum.repos.d/epel.repo) o instalar el paquete epel-release que crea el archivo automáticamente, sin modificar mi configuración predeterminada o causar conflictos de archivo que No es necesario que suceda.

Lo que sucederá es que la mayoría de los programas leerán su configuración predeterminada ( /etc/yum.confpor ejemplo) y luego iterarán sobre sus .dcarpetas, incluidos los fragmentos de configuración en el programa en ejecución.

Espero que te lo explique.

Al igual que los archivos pueden tener .extque especificar qué tipo de archivo es (comúnmente llamado "extensión"), los directorios a veces tienen .dque mostrar que es un directorio y no un archivo. Ese es su tipo. La lssalida predeterminada no diferencia visualmente directorios y archivos, por lo que .des solo una convención antigua para mostrar su tipo (directorio) en dichos listados.

En términos más generales, los directorios .d (/etc/httpd/conf.d, /etc/rc.d, / etc / siendo otro ejemplo), indican que los archivos contenidos serán leídos y utilizados, a menudo para la configuración, si coinciden un patrón dado y no requieren ser agregados explícitamente a alguna lista maestra.

Entonces, si agrega archivos de la forma * .repo a /etc/yum.repos.d, yum lo usará cuando se ejecute sin necesidad de agregarlo a una lista de configuraciones /etc/yum.conf. Si agrega archivos de la forma * .conf a /etc/http/conf.d, Apache los leerá sin necesidad de agregarlos explícitamente a /etc/httpd/conf/httpd.conf. Del mismo modo, chkconfig a archivos en /etc/init.d, trabajos cron en /etc/cron.d.

Creo, pero no puedo documentar, que la .dindica que el directorio está asociado con un d Aemon.

La evidencia indicaría que esto es al menos plausible:

sudo find / -maxdepth 3 -name "*.d"

^{_{En algún lugar en los profundos recovecos de los pequeños fragmentos de la antigua historia de Unix que todavía resuenan en el fondo de mi mente detrás de las telarañas, esto me llama la respuesta correcta. Creo que puede haber sido de una época en que los primeros mamíferos vagaron por la tierra antes de que los dinosaurios comenzaran a desaparecer y las manpáginas no solo se mantuvieran en el sistema, sino también físicamente en bastidores medidos por el pie.}}