it-swarm.it

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 ciò che il .d significa, ma il titolo della mia domanda non è stato scelto bene. Ho cambiato "mean" in "stand".

123
greg0ire

Il .d suffisso qui significa directory. Naturalmente, ciò non sarebbe necessario poiché Unix non richiede un suffisso per indicare un tipo di file ma in quel caso specifico, era necessario qualcosa per chiarire i comandi (/etc/init, /etc/rc0, /etc/rc1 e 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 comando init si trovava in /etc ma ora è generalmente in /sbin sui moderni sistemi operativi System V.

Si noti che questa convenzione è stata adottata da molte applicazioni che passano 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 è quello di 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.

108
jlliagre

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 tutto ciò che era caduto in quella directory sarebbe diventato attivo 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 utilizzate 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, il motivo del ".d", la mia ipotesi migliore sarebbe "distribuita", come in non parte del file di configurazione principale, ma comunque parte della configurazione.

58
E-man

Se parli di ".d" alla fine dei nomi di directory, questa risposta è giusto, è 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 la dissociazione del processo daemon da qualsiasi controllo tty. A tale scopo esistono routine di convenienza come daemon (3) in alcuni sistemi UNIX.

12
Philomath

Non significa directory di per sé, in pratica ciò che sta accadendo è che le directory che finiscono in .d (nota che di solito sono sempre e solo in /etc), accetta le parti di configurazione.

Questo è progettato in modo che le distribuzioni possano includere valori predefiniti universali ad esempio /etc/yum.conf, ma poi 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 utilizzare EPEL sul mio RHEL5 o CentOS Box, posso configurare un nuovo repository nel /etc/yum.repos.d cartella, (dire /etc/yum.repos.d/epel.repo) o installa il pacchetto epel-release che crea automaticamente il file, senza modificare la mia configurazione predefinita o causare conflitti di file che non devono verificarsi.

Ciò che accadrà è che la maggior parte dei programmi leggerà la loro configurazione predefinita (/etc/yum.conf ad esempio) e quindi scorrere i loro .d cartelle inclusi i frammenti di configurazione nel programma in esecuzione.

Spero che lo spieghi per te.

4
N J

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

3
Keith

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.

2
Tim

Penso, ma non posso documentare, che il .d indica che la directory è associata a daemon.

Le prove indicano che questo è almeno plausibile:

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

Da qualche parte nei profondi recessi dei piccoli frammenti della storia antica di Unix ancora tintinnando 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 man pagine non erano solo tenute sul sistema ma anche fisicamente in rack misurati dal piede.