Que signifie le .d dans les noms de répertoire?

118

Je connais beaucoup de répertoires avec .d dans leur nom:

init.d
yum.repos.d
conf.d

Est-ce que cela signifie répertoire? Si oui, de quoi cela désambiguise?

MISE À JOUR: J'ai eu beaucoup de réponses intéressantes sur ce que .dsignifie le moyen, mais le titre de ma question n'a pas été bien choisi. J'ai changé "moyen" pour "représenter".

greg0ire
la source
9
Pour l'origine de .d, voir le commentaire de msw sur cette question connexe à l' adresse Ask Ubuntu .
Gilles
@ Gilles, ah, je pensais que c'était plus tard que System-V, mais oui, même s'il n'a toujours pas de sens, ".d" a été choisi parmi ce que je peux dire.
NJ
@Gilles: intéressant, la réponse semble être: l'explication a été perdue ... selon le premier commentaire de la première réponse dans votre lien
greg0ire
Je ne sais pas pourquoi .ddans init.d, mais il semble presque tous les fichiers de configuration personnalisés vont à des .drépertoires dans RHEL / CentOS / Fedora.
LiuYan 研 研
@ Liu Yan - En effet, je ne pouvais pas l'expliquer d'une manière qui puisse être interprétée comme étant cohérente.
Tim Post

Réponses:

102

Le .dsuffixe signifie ici répertoire. Bien sûr, cela ne serait pas nécessaire que Unix ne nécessite pas de suffixe pour désigner un type de fichier , mais dans ce cas précis, quelque chose était nécessaire pour désambiguïser les commandes ( /etc/init, /etc/rc0, /etc/rc1etc.) et les répertoires qu'ils utilisent ( /etc/init.d, /etc/rc0.d, /etc/rc1.d,. ..)

Cette convention a été introduite au moins avec Unix System V mais peut-être plus tôt. Auparavant, la initcommande se trouvait dans, /etcmais elle est généralement utilisée dans /sbinles systèmes d'exploitation System V modernes.

Notez que cette convention a été adoptée par de nombreuses applications passant d’un fichier de configuration de fichier unique à plusieurs fichiers de configuration situés dans un même répertoire, par exemple: /etc/sudoers.d

Là encore, l'objectif est d'éviter les conflits de noms, non pas entre l'exécutable et le fichier de configuration, mais entre l'ancien fichier de configuration monolithique et le répertoire qui les contient.

jlliagre
la source
4
+1, je pense que vous avez raison, mais personne à ce jour n'a donné de citation pour sa théorie
greg0ire
C'est plus une convention qui a grandi sur les gens qu'une norme explicite réelle, je pense
Shadur
1
Lorsque vous exécutez une lscommande (ou pas ls -al) sans utiliser l' --coloroption (spécifiée explicitement ou faisant partie d' LS_OPTIONSune variable d'environnement), le ".d" permet aux répertoires de se distinguer de la liste. C'est pourquoi j'ai toujours pensé que c'était fait.
LawrenceC
^ colorn’est pas le seul, ni le meilleur moyen de marquer visuellement les annuaires. ls -Fva faire cela et beaucoup d'autres choses utiles.
underscore_d
56

Extrait d'une liste de diffusion Debian (soulignement ajouté):

Lorsque le conditionnement de la distribution est devenu de plus en plus courant, il est devenu évident que nous avions besoin de meilleures méthodes pour former ces fichiers de configuration à partir de plusieurs fragments, souvent fournis par plusieurs packages indépendants. Chaque package devant configurer un service partagé doit pouvoir gérer uniquement sa configuration sans avoir à éditer un fichier de configuration partagé utilisé par d'autres packages.

La convention la plus commune adoptée était d'autoriser l'inclusion d'un répertoire plein de fichiers de configuration, où tout ce qui y serait déposé deviendrait actif et ferait partie de cette configuration. Au fur et à mesure que cette convention se généralisait, ce répertoire était généralement nommé d'après le fichier de configuration qu'il remplaçait ou augmentait. Mais comme on ne peut pas avoir un répertoire et un fichier portant le même nom, il a fallu une méthode pour faire la distinction. Le fichier .d a donc été ajouté à la fin du nom du fichier de configuration. Par conséquent, un fichier de configuration / etc / Muttrc a été augmenté par des fragments dans /etc/Muttrc.d, / etc / bash_completion a été augmenté avec /etc/bash_completion.d/*, etc. Parfois, de légères variations sur cette convention sont utilisées, telles que /etc/xinetd.d pour compléter /etc/xinetd.conf ou / etc / apache2 / conf. d pour compléter /etc/apache2/apache2.conf. Mais c'est la même idée de base.

Généralement, lorsque vous voyez cette convention * .d, cela signifie "il s'agit d'un répertoire contenant un groupe de fragments de configuration qui seront fusionnés dans la configuration d'un service."


Pour la partie 2, la raison du ".d", ma meilleure hypothèse serait "distribué", car elle ne fait pas partie du fichier de configuration principal, mais fait toujours partie de la configuration .

E-man
la source
8
Surprenant ... J'aurais pensé que cela parlait en faveur du "répertoire", ce qui signifie "ceci est la partie répertoire de la configuration".
greg0ire
2
C'est clairement le cas. Pourquoi quelqu'un lirait ceci et conclurait-il que cela .dsignifiait autre chose me dépasse! Mais cette source ne montre que les raisons qui ont poussé Debian à utiliser, dans un seul contexte, une convention qui existait depuis les débuts d’Unix. Je me demande si ce responsable de Debian simplifiait délibérément - ou pensait vraiment que Debian avait inventé cette pratique.
underscore_d
11

Si vous parlez de ".d" à la fin des noms de répertoires, cette réponse est juste, c'est juste un marqueur de "répertoire".

Il suffit de ne pas le confondre avec "d" à la fin d'un nom de fichier, comme "syslogd", qui signifie démon . Un processus informatique en cours d'exécution en arrière-plan.

le processus parent d'un démon est souvent (mais pas toujours) le processus init (PID = 1). Les processus deviennent généralement des démons en forçant un processus enfant, puis en laissant leur processus parent immédiatement quitter, ce qui oblige init à adopter le processus enfant. Il s’agit d’une vue quelque peu simplifiée du processus car d’autres opérations sont généralement effectuées, telles que la dissociation du processus démon de tout terminal de contrôle. Des routines pratiques telles que daemon (3) existent dans certains systèmes UNIX à cette fin.

Philomath
la source
Pas vraiment, ce sont des noms de répertoire.
Keith
@ Keith: oups, j'ai pensé à tort qu'il parlait de fichiers se terminant par "d", comme syslogd, pas de répertoires se terminant par ".d". Je vais éditer bientôt.
Philomath
C'est ce que je pensais, mais je le vois souvent utilisé dans les répertoires de configuration pour les programmes qui ne démonalisent pas , par exemple sysctl.d, modprobe.dserait-ce une utilisation inappropriée?
Tim Post
@ Tim Post: voir les 2 commentaires ci-dessus (et la réponse de Keith), je vais bientôt modifier ma réponse.
Philomath
Édité (15 chr)
Philomath le
4

Cela ne signifie pas répertoire en tant que tel, ce qui se passe en fait, c’est que les répertoires qui se terminent par .d(notez qu’ils ne le sont généralement que par jamais /etc), prennent des éléments de configuration.

Ceci est conçu pour que les distributions puissent inclure des valeurs par défaut universelles, par exemple /etc/yum.conf, mais il existe ensuite une méthode facile à utiliser pour les utilisateurs ou d’autres packages qui permet d’ajouter leurs propres configurations yum de manière sécurisée et non écrasée.

Par exemple pour miam ...

Si je veux commencer à utiliser EPEL sur mon boîtier RHEL5 ou CentOS, je peux configurer un nouveau référentiel dans le /etc/yum.repos.ddossier (par exemple /etc/yum.repos.d/epel.repo) ou installer le package epel-release qui crée le fichier automatiquement, sans modifier ma configuration par défaut ni provoquer de conflits de fichiers pas besoin d'arriver.

Ce qui va arriver, c'est que la plupart des programmes liront leur configuration par défaut ( /etc/yum.confpar exemple), puis itéreront dans leurs .ddossiers, y compris des extraits de configuration, dans le programme en cours d'exécution.

J'espère que ça l'explique pour vous.

New Jersey
la source
+1, cela explique beaucoup, mais ... pas le choix de la lettre 'd'.
greg0ire
1
Doit-il y avoir une explication pour le choix? Il s’agit simplement d’une convention qui s’est développée au fil du temps, elle n’est pas (d’un coup d’œil rapide) définie dans la FHS, mais elle peut être incluse dans la norme LSB. Cron était l'un des premiers, si je me souviens bien. (Edit: en fait, cela aurait été init)
NJ
3

Tout comme les fichiers peuvent devoir .extspécifier leur type (généralement appelé "extension"), les répertoires doivent parfois .dindiquer que c'est un répertoire et non un fichier. C'est son type. La lssortie par défaut ne différencie pas visuellement les répertoires et les fichiers. Il .ds'agit donc simplement d'une ancienne convention pour afficher son type (répertoire) dans de telles listes.

Keith
la source
6
De plus, le .dsuffixe empêche les collisions avec un fichier portant le même nom. Par exemple, vous pouvez avoir un fichier de configuration /etc/apt/sources.listet un répertoire de fichiers de configuration /etc/apt/sources.list.d.
Jmtd
2
^ J'irais jusqu'à dire que ce n'est pas un "ajout" mais la raison même de la convention. Unix / Linux n'a jamais été précieux d'inclure des extensions, en particulier dans les premiers jours, donc je doute que celui-ci ait été utilisé sans raison.
underscore_d
2

Plus généralement, les répertoires .d (/etc/httpd/conf.d, /etc/rc.d, / etc / étant un autre exemple) indiquent que les fichiers contenus seront lus et utilisés, souvent pour la configuration, s’ils correspondent. un modèle donné et ne nécessitent pas d’être explicitement ajouté à une liste maîtresse.

Donc, si vous ajoutez des fichiers de la forme * .repo à /etc/yum.repos.d, yum l’utilisera lorsqu’il sera exécuté sans avoir besoin de l’ajouter à une liste de configurations /etc/yum.conf. Si vous ajoutez des fichiers de la forme * .conf à /etc/http/conf.d, ils seront lus par Apache sans qu'il soit nécessaire de les ajouter explicitement à /etc/httpd/conf/httpd.conf. De même, chkconfig dans les fichiers de /etc/init.d, les travaux cron dans /etc/cron.d.

Tim
la source
+1, mais ... même remarque que ci-dessus.
greg0ire
1
@greg: En raison de la variété des méthodes de tri des réponses, les expressions «au-dessus» et «au-dessous» sont des méthodes peu efficaces pour renvoyer (commenter) d'autres réponses. Les types «plus ancien» et «plus récent» produisent des significations opposées pour de telles descriptions basées sur la position, et lors du tri par «votes», la position relative de deux réponses peut changer avec le temps.
Chris Johnsen
@ Chris Johnsen: c'est ce que j'ai compris, mais trop tard. Je faisais référence à mon commentaire sur la réponse de NJ.
greg0ire
1

Je pense, mais ne peut pas documenter, que l' .dindique que le répertoire est associé à un d Aemon.

Les preuves indiqueraient que cela est au moins plausible:

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

Quelque part dans les profonds recoins des fragments de l’histoire ancienne d’Unix qui remue encore dans l’esprit derrière les toiles d’araignées, c’est la bonne réponse. Je pense que cela vient peut-être du moment où les premiers mammifères parcouraient la terre avant que les dinosaures ne commencent à disparaître et que des manpages étaient non seulement conservées sur le système, mais aussi physiquement dans des supports mesurés par le pied.

Dennis Williamson
la source
+1 pour le délire à la fin, mais je pense que cela ne va pas bien avec yum.repos.d ...
greg0ire
</cobwebs>Je crois que les réponses qui indiquent que le but de .dest de distinguer le répertoire des fichiers associés et portant le même nom sont les bonnes. J'ai voté E-man et Jlliagre.
Dennis Williamson
La question est "qu'est-ce que le '.d' veut dire", et j'ai reçu de nombreuses explications concernant la raison pour laquelle il y a ce ".d", mais les rares qui ont donné une réponse concernant le sens ne citaient aucune source. Personnellement, je pense que cela signifie répertoire.
greg0ire
1
yumest une invention plus récente.
Dennis Williamson