Cosa significa .d nei nomi di directory?

Conosco molte directory con .d nel loro nome:

init.d
yum.repos.d
conf.d

Significa directory? In caso affermativo, da cosa si discosta?

AGGIORNAMENTO: Ho avuto molte risposte interessanti su cosa .dsignifichi, ma il titolo della mia domanda non è stato scelto bene. Ho cambiato "mean" in "stand".

Il .dsuffisso qui significa directory. Naturalmente, questo sarebbe inutile, in quanto Unix non richiede un suffisso per indicare un tipo di file, ma in quel caso specifico, qualcosa è stato necessario per disambiguare i comandi ( /etc/init, /etc/rc0, /etc/rc1e così via) e le directory che usano ( /etc/init.d, /etc/rc0.d, /etc/rc1.d,. ..)

Questa convenzione è stata introdotta almeno con Unix System V ma probabilmente prima. Il initcomando si trovava in /etcma ora si trova nei /sbinmoderni sistemi operativi System V.

Si noti che questa convenzione è stata adottata da molte applicazioni che si spostano da un singolo file di configurazione a più file di configurazione situati in una singola directory, ad esempio: /etc/sudoers.d

Anche in questo caso, l'obiettivo è evitare lo scontro tra nomi, non tra il file eseguibile e il file di configurazione, ma tra il precedente file di configurazione monolitico e la directory che li contiene.

Estratto da una mailing list Debian (enfasi aggiunta):

Quando il packaging di distribuzione divenne sempre più comune, divenne chiaro che avevamo bisogno di modi migliori per formare tali file di configurazione da più frammenti, spesso forniti da più pacchetti indipendenti. Ogni pacchetto che deve configurare alcuni servizi condivisi dovrebbe essere in grado di gestire solo la sua configurazione senza dover modificare un file di configurazione condiviso utilizzato da altri pacchetti.

La convenzione più comune adottata era quella di consentire l'inclusione di una directory piena di file di configurazione, in cui qualsiasi cosa rilasciata in quella directory sarebbe diventata attiva e parte di quella configurazione. Man mano che quella convenzione diventava più diffusa, quella directory veniva di solito chiamata come il file di configurazione che stava sostituendo o aumentando. Ma poiché non è possibile avere una directory e un file con lo stesso nome, è stato necessario distinguere alcuni metodi, quindi .d è stato aggiunto alla fine del nome del file di configurazione. Quindi, un file di configurazione / etc / Muttrc è stato aumentato da frammenti in /etc/Muttrc.d, / etc / bash_completion è stato aumentato con /etc/bash_completion.d/* e così via. A volte vengono usate lievi variazioni su quella convenzione, come /etc/xinetd.d per integrare /etc/xinetd.conf o / etc / apache2 / conf. d per integrare /etc/apache2/apache2.conf. Ma è la stessa idea di base.

Generalmente quando vedi quella convenzione * .d, significa "questa è una directory che contiene un mucchio di frammenti di configurazione che verranno uniti nella configurazione per alcuni servizi".

Per la parte 2, la ragione del ".d", la mia ipotesi migliore sarebbe "distribuita", come non parte del file di configurazione principale, ma comunque parte della configurazione .

Se parli di ".d" alla fine dei nomi di directory, questa risposta è corretta, è solo un indicatore per "directory".

Basta non confonderlo con "d" in corrispondenza del nome di un file, come "syslogd", che sta per demone . Un processo informatico in esecuzione in background.

il processo genitore di un demone è spesso (ma non sempre) il processo init (PID = 1). I processi di solito diventano demoni biforcando un processo figlio e quindi facendo uscire immediatamente il loro processo genitore, facendo sì che init adotti il ​​processo figlio. Questa è una visione un po 'semplificata del processo in quanto vengono generalmente eseguite altre operazioni, come dissociare il processo daemon da qualsiasi tty di controllo. A tale scopo esistono routine di convenienza come daemon (3) in alcuni sistemi UNIX.

Non significa directory di per sé, fondamentalmente quello che sta succedendo è che le directory che finiscono .d(nota che di solito sono sempre e solo in /etc), prendono parti di configurazione.

Questo è progettato in modo tale che le distribuzioni possano includere impostazioni predefinite universali, ad esempio /etc/yum.conf, ma esiste un metodo facile da usare per gli utenti o altri pacchetti per aggiungere le proprie configurazioni yum in un modo sicuro che non verrà sovrascritto.

Ad esempio per yum ...

Se volessi iniziare a usare EPEL sul mio RHEL5 o CentOS Box, posso configurare un nuovo repository nella /etc/yum.repos.dcartella, (diciamo /etc/yum.repos.d/epel.repo) o installare il pacchetto epel-release che crea automaticamente il file, senza modificare la mia configurazione predefinita o causare conflitti di file che non è necessario che accada.

Ciò che accadrà è che la maggior parte dei programmi leggerà la loro configurazione predefinita ( /etc/yum.confad esempio) e quindi scorrerà le loro .dcartelle, inclusi i frammenti di configurazione, nel programma in esecuzione.

Spero che lo spieghi per te.

Proprio come i file possono dover .extspecificare quale tipo di file è (comunemente chiamato "estensione"), le directory a volte devono .dmostrare che è una directory e non un file. Questo è il suo tipo. L' lsoutput predefinito non differenzia visivamente directory e file, quindi .dè solo una vecchia convenzione per mostrare il suo tipo (directory) in tali elenchi.

Più in generale, le directory .d (/etc/httpd/conf.d, /etc/rc.d, / etc / essendo un altro esempio), indicano che i file contenuti saranno letti e usati, spesso per la configurazione, se corrispondono un determinato modello e non richiede l'aggiunta esplicita a un elenco principale.

Quindi se aggiungi file del modulo * .repo a /etc/yum.repos.d, yum lo userà durante l'esecuzione senza la necessità di aggiungerlo a un elenco di configurazioni /etc/yum.conf. Se aggiungi file del modulo * .conf a /etc/http/conf.d, verranno letti da Apache senza che sia necessario aggiungere esplicitamente a /etc/httpd/conf/httpd.conf. Allo stesso modo, chkconfig ai file in /etc/init.d, cron lavori in /etc/cron.d.

Credo, ma non riesco a documentare, che la .dindica che la directory è associato a un d Aemon.

La prova indicherebbe che questo è almeno plausibile:

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

^{_{Da qualche parte nei profondi recessi dei piccoli frammenti della storia antica di Unix che ancora tintinnano nella parte posteriore della mia mente dietro le ragnatele, questo mi chiama come la risposta corretta. Credo che potrebbe provenire da un'epoca in cui i primi mammiferi vagavano per la terra prima che i dinosauri iniziassero a estinguersi e le manpagine non solo fossero mantenute sul sistema, ma anche fisicamente in scaffali misurati dal piede.}}