Wofür steht die .d in Verzeichnisnamen?

118

Ich kenne viele Verzeichnisse mit .d im Namen:

init.d
yum.repos.d
conf.d

Bedeutet das Verzeichnis? Wenn ja, woraus ergibt sich eine eindeutige Unterscheidung?

UPDATE: Ich hatte viele interessante Antworten, was das .dbedeutet, aber der Titel meiner Frage war nicht gut gewählt. Ich habe "mean" geändert, um für "zu stehen".

greg0ire
quelle
9
Zum Ursprung von .dsiehe msws Kommentar zu dieser verwandten Frage bei Ask Ubuntu .
Gilles
@ Gilles, ha, ich dachte, es wäre später als System-V, aber ja, es gibt immer noch keine Bedeutung für '.d', es wurde nur aus dem ausgewählt, was ich sagen kann.
NJ
@ Gilles: Interessant, die Antwort scheint zu sein: Die Erklärung ging verloren ... laut dem ersten Kommentar der ersten Antwort in deinem Link
greg0ire
Ich bin mir nicht sicher, warum .din init.d, aber es scheint, dass fast alle benutzerdefinierten Konfigurationsdateien in .dVerzeichnisse in RHEL / CentOS / Fedora verschoben werden.
LiuYan 刘 研
@Liu Yan - In der Tat konnte ich es auf keine Weise erklären, die als konsequent ausgelegt werden könnte.
Tim Post

Antworten:

102

Das .dSuffix bedeutet hier Verzeichnis. Natürlich wäre dies nicht notwendig , da Unix einen Dateityp zu bezeichnen , kein Suffix erfordert aber in diesem speziellen Fall etwas notwendig war , die Befehle (eindeutig zu machen /etc/init, /etc/rc0, /etc/rc1usw.) und die Verzeichnisse sie verwenden ( /etc/init.d, /etc/rc0.d, /etc/rc1.d,. ..)

Diese Konvention wurde zumindest mit Unix System V eingeführt, möglicherweise jedoch früher. Der initBefehl befand sich früher in, befindet sich /etcaber jetzt in der Regel in /sbinmodernen System V-Betriebssystemen.

Beachten Sie, dass diese Konvention von vielen Anwendungen übernommen wurde, die von einer Konfigurationsdatei in mehrere Konfigurationsdateien in einem einzigen Verzeichnis verschoben wurden, z. /etc/sudoers.d

Auch hier besteht das Ziel darin, Namenskonflikte zu vermeiden, und zwar nicht zwischen der ausführbaren Datei und der Konfigurationsdatei, sondern zwischen der früheren monolithischen Konfigurationsdatei und dem Verzeichnis, in dem sie enthalten sind.

jlliagre
quelle
4
+1, ich denke du hast recht, aber bisher hat noch niemand ein Zitat für seine Theorie abgegeben
greg0ire
Ich denke, es ist eher eine Konvention, die sich auf Menschen
bezieht,
1
Wenn Sie einen lsBefehl ausführen (nicht ls -al), ohne die --colorOption zu verwenden (entweder explizit angegeben oder Teil der LS_OPTIONSUmgebungsvariablen), heben sich Verzeichnisse durch die Angabe von ".d" von der Liste ab. Deshalb dachte ich immer, dass es getan wurde.
LawrenceC
^ colorist nicht die einzige oder beste Möglichkeit, Verzeichnisse visuell zu kennzeichnen. ls -Fwerde das und viele weitere nützliche Dinge tun.
Underscore_d
56

Auszug aus einer Debian-Mailingliste (Hervorhebung hinzugefügt):

Mit zunehmender Verbreitung von Distributionspaketen wurde klar, dass wir bessere Möglichkeiten benötigen, solche Konfigurationsdateien aus mehreren Fragmenten zu erstellen, die häufig von mehreren unabhängigen Paketen bereitgestellt werden. Jedes Paket, das einen gemeinsam genutzten Dienst konfigurieren muss, sollte nur seine Konfiguration verwalten können, ohne eine gemeinsam genutzte Konfigurationsdatei bearbeiten zu müssen, die von anderen Paketen verwendet wird.

Die gebräuchlichste Konvention bestand darin, das Einfügen eines Verzeichnisses mit Konfigurationsdateien zuzulassen, in das alles, was in diesem Verzeichnis abgelegt wurde, aktiv und Teil dieser Konfiguration wird. Mit zunehmender Verbreitung dieser Konvention wurde dieses Verzeichnis normalerweise nach der Konfigurationsdatei benannt, die ersetzt oder erweitert wurde. Da es jedoch kein Verzeichnis und keine Datei mit demselben Namen geben kann, war zur Unterscheidung eine Methode erforderlich, sodass .d an das Ende des Namens der Konfigurationsdatei angehängt wurde. Daher wurde eine Konfigurationsdatei / etc / Muttrc um Fragmente in /etc/Muttrc.d erweitert, / etc / bash_completion wurde um /etc/bash_completion.d/* usw. erweitert. Manchmal werden geringfügige Abweichungen von dieser Konvention verwendet, z. B. /etc/xinetd.d, um /etc/xinetd.conf oder / etc / apache2 / conf zu ergänzen. d ergänzen /etc/apache2/apache2.conf. Aber es ist die gleiche Grundidee.

Wenn Sie diese * .d-Konvention sehen, bedeutet dies im Allgemeinen, dass "dies ein Verzeichnis ist, das eine Reihe von Konfigurationsfragmenten enthält, die für einen bestimmten Dienst in der Konfiguration zusammengeführt werden."


Für Teil 2, den Grund für das ".d", würde ich nach bestem Wissen "verteilt" sein, da dies nicht Teil der Hauptkonfigurationsdatei, sondern immer noch Teil der Konfiguration ist .

E-Mann
quelle
8
Überraschend ... Ich hätte gedacht, dass dies für das "Verzeichnis" spricht, was bedeutet, dass "dies der Verzeichnisteil der Konfiguration ist".
greg0ire
2
Es ist klar. Warum jemand dies lesen und daraus schließen würde, dass das .dBedeutete , dass alles andere für mich unverständlich ist! Diese Quelle zeigt jedoch nur Debians Gründe, in einem Kontext eine Konvention zu verwenden, die seit den Anfängen von Unix existierte. Ich muss mich fragen, ob dieser Debian-Betreuer absichtlich vereinfacht hat - oder ob Debian diese Praxis wirklich erfunden hat.
Underscore_d
11

Wenn Sie am Ende der Verzeichnisnamen von ".d" sprechen, ist diese Antwort richtig, es ist nur eine Markierung für "Verzeichnis".

Verwechseln Sie es nur nicht mit "d" am und eines Dateinamens wie "syslogd", der für daemon steht . Ein Computerprozess, der im Hintergrund ausgeführt wird.

Der übergeordnete Prozess eines Daemons ist häufig (aber nicht immer) der Init-Prozess (PID = 1). Prozesse werden in der Regel zu Dämonen, indem ein untergeordneter Prozess gegabelt und der übergeordnete Prozess sofort beendet wird, sodass init den untergeordneten Prozess übernimmt. Dies ist eine etwas vereinfachte Ansicht des Prozesses, da im Allgemeinen andere Vorgänge ausgeführt werden, z. B. das Trennen des Daemon-Prozesses von einer Steuerung. Zu diesem Zweck gibt es in einigen UNIX-Systemen praktische Routinen wie Daemon (3).

Philomath
quelle
Nicht wirklich, das sind Verzeichnisnamen.
Keith
@Keith: Hoppla, ich dachte fälschlicherweise, er spricht von Dateien, die mit "d" enden, syslogdund nicht von Verzeichnissen, die mit ".d" enden. Ich bearbeite gleich.
Philomath
Das ist , was ich dachte, aber ich sehe es oft für Programme in Konfigurationsverzeichnissen verwendet , die nicht daemonize, zum Beispiel sysctl.d, modprobe.d.. wäre , dass eine unangemessene Verwendung sein?
Tim Post
@ Tim Post: Siehe die obigen 2 Kommentare (und die Antwort von Keith), ich bearbeite bald meine Antwort.
Philomath
Bearbeitet (15 chr)
Philomath
4

.dDies bedeutet nicht, dass Verzeichnisse per se sind. Im Grunde geschieht, dass Verzeichnisse, die auf enden (beachten Sie, dass diese normalerweise immer auf enden /etc), Konfigurationsteile enthalten.

Dies ist so konzipiert, dass Distributionen beispielsweise universelle Standardeinstellungen enthalten können. Es /etc/yum.confgibt jedoch eine einfach zu verwendende Methode für Benutzer oder andere Pakete, um ihre eigenen yum-Konfigurationen auf sichere Weise anzufügen, die nicht überschrieben werden.

Als Beispiel für yum ...

Wenn ich EPEL auf meiner RHEL5- oder CentOS-Box verwenden möchte, kann ich ein neues Repository im /etc/yum.repos.dOrdner konfigurieren (sagen wir /etc/yum.repos.d/epel.repo) oder das Epel-Release-Paket installieren, das die Datei automatisch erstellt, ohne meine Standardkonfiguration zu ändern oder Dateikonflikte zu verursachen muss nicht passieren.

Was passieren wird, ist, dass die meisten Programme ihre Standardkonfiguration lesen ( /etc/yum.confzum Beispiel) und dann über ihre .dOrdner, einschließlich Konfigurationsschnipsel, in das laufende Programm iterieren .

Hoffe, es erklärt es für Sie.

NJ
quelle
+1, das erklärt eine Menge, aber ... nicht die Wahl des Buchstabens 'd'.
greg0ire 13.11.10
1
Muss es eine Erklärung für die Wahl geben? Es ist nur eine Konvention, die sich im Laufe der Zeit entwickelt hat. Sie ist nicht (aus einem kurzen Blickwinkel) in der FHS definiert, kann aber in den LSB-Standard aufgenommen werden. Cron war einer der ersten, wie ich mich erinnere. (Edit: in der Tat wäre es Init gewesen)
NJ
3

Genauso wie Dateien .extangeben müssen , um welchen Dateityp es sich handelt (üblicherweise als "Erweiterung" bezeichnet), müssen Verzeichnisse manchmal anzeigen .d, dass es sich um ein Verzeichnis und nicht um eine Datei handelt. Das ist sein Typ. Bei der Standardausgabe lswerden Verzeichnisse und Dateien nicht visuell unterschieden. Daher .dist es nur eine alte Konvention, den Typ (das Verzeichnis) in solchen Auflistungen anzuzeigen.

Keith
quelle
6
Außerdem .dverhindert das Suffix Kollisionen mit einer Datei mit ähnlichem Namen. Beispielsweise können Sie eine Konfigurationsdatei /etc/apt/sources.listund ein Verzeichnis mit Konfigurationsdateien haben /etc/apt/sources.list.d.
jmtd
2
^ Ich würde sogar sagen, dass dies keine "Ergänzung" ist, sondern der eigentliche Grund für den Kongress. Unix / Linux hat es nie gekostet, Erweiterungen an Dingen vornehmen zu müssen, besonders in den frühen Tagen. Ich bezweifle, dass diese ohne guten Grund herumgespielt wurden.
Underscore_d
2

Im Allgemeinen geben die Verzeichnisse .d (/etc/httpd/conf.d, /etc/rc.d, / etc / als weiteres Beispiel) an, dass die enthaltenen Dateien gelesen und häufig zur Konfiguration verwendet werden, wenn sie übereinstimmen ein bestimmtes Muster und müssen nicht explizit zu einer Master-Liste hinzugefügt werden.

Wenn Sie also Dateien der Form * .repo zu /etc/yum.repos.d hinzufügen, wird sie von yum beim Ausführen verwendet, ohne dass Sie sie einer Konfigurationsliste /etc/yum.conf hinzufügen müssen. Wenn Sie Dateien der Form * .conf zu /etc/http/conf.d hinzufügen, werden sie von Apache gelesen, ohne dass dies explizit zu /etc/httpd/conf/httpd.conf hinzugefügt werden muss. Ebenso chkconfig auf Dateien in /etc/init.d, cron jobs in /etc/cron.d.

Tim
quelle
+1, aber ... gleiche Bemerkung wie oben.
greg0ire 13.11.10
1
@greg: Aufgrund der Vielzahl von Möglichkeiten, Antworten zu sortieren, sind "oben" und "unten" schlechte Möglichkeiten, auf andere Antworten zu verweisen (Kommentare zu diesen). Die "ältesten" und "neuesten" Sorten ergeben für solche positionsbasierten Beschreibungen entgegengesetzte Bedeutungen, und wenn nach "Stimmen" sortiert wird, kann sich die relative Position zweier Antworten im Laufe der Zeit ändern.
Chris Johnsen
@ Chris Johnsen: das ist mir klar geworden, aber zu spät. Ich bezog mich auf meinen Kommentar zu NJs Antwort.
greg0ire
1

Ich denke, kann aber nicht dokumentieren, dass das .danzeigt, dass das Verzeichnis einem D aemon zugeordnet ist.

Hinweise würden darauf hindeuten, dass dies zumindest plausibel ist:

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

Irgendwo in den tiefen Nischen der kleinen Teile der alten Unix-Geschichte, die immer noch im Hinterkopf hinter den Spinnweben herumwirbeln, erscheint mir dies als die richtige Antwort. Ich glaube, es könnte aus einer Zeit stammen, als die ersten Säugetiere die Erde durchstreiften, bevor die Dinosaurier auszusterben begannen und manSeiten nicht nur im System, sondern auch physisch in Gestellen, gemessen am Fuß, aufbewahrt wurden.

Dennis Williamson
quelle
+1 für das Delirium am Ende, aber ich denke, das passt nicht gut zu yum.repos.d ...
greg0ire
</cobwebs>Ich glaube, dass die Antworten, die darauf hindeuten, dass der Zweck der .dist, das Verzeichnis von den verwandten und ähnlich benannten Dateien zu trennen, die richtigen sind. Ich habe E-man's und jlliagre's upvoted.
Dennis Williamson
Die Frage ist "Wofür steht das" .d "", und ich habe viele Erklärungen zu dem Grund erhalten, warum es das ".d" gibt, aber die wenigen, die eine Antwort bezüglich der Bedeutung gaben, haben keine Quelle angegeben. Persönlich denke ich, dass es Verzeichnis bedeutet.
greg0ire
1
yumist eine neuere Erfindung.
Dennis Williamson