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

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".

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.

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 .

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.

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.

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.

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.

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.}}