Bonjour à Tous,

Pas évident de trouver la réponse à cette interrogation en utilisant les moteurs de recherche...
Comment voulez-vous faire une recherche avec une seule lettre :lol:

Comme il y pas mal de linuxiens de longue date ici, je tente ma chance :
Que signifie le ".d" qui se trouve à la fin de certains répertoires dans /etc/
(profile.d, init.d, yum.repos.d) ?

Je suppose que c'est l'initiale de quelque chose.
Intuitivement je me serais dit : "Directory", mais plutôt qu'une supposition, je préférerai avoir une certitude 😉

Si quelqu'un peut m'éclairer...
Salut,

Quand tu touche les /init.d/xxx, tu interagis avec les daemon, je pencherais donc pour daemon !

Je ne suis cependant pas un expert en la matière, ce n'est que mon idée...

Cordialement
J'y avais pensé également au départ, mais cela me semblait moins cohérent avec des répertoires comme profile.d ou sane.d

J'espérais trouver la réponse dans la FHS, mais à moins d'être passé au-dessus, je reste pour l'instant bredouille 😃

Merci pour ton intervention, avec un peu de chance on va voir si quelqu'un confirme ou non 😉
ça peut pas etre "directory", ça veut dire dossier, et il y en a partout des dossiers.
c'est historique. A l'origine la plupart des ces dossiers etaient des fichiers qui sont ensuite été découpé en plusieurs fichiers. Le fichier originel c'est vu ajouté .d quand il est devenu un dossier. C'est fort probablement l'initial de directory.

/etc/php.conf -> /etc/php.d/*.conf
/etc/yum.repo.conf? -> /etc/yum.repos.d/*.conf
modeprobe.conf -> modeprobe.d/*.conf

Je suis pas sur de mon coup pour init.d...
Pas de réponse sure, mais pour moi le .d signifie bien directory.

On le trouve sur les dossiers qui contiennent des fichiers de configuration.
Dans un fichier de conf tel que yum.conf ou httpd.conf, on n'écrit pas toute la conf du logiciel, pour des raisons d'esthetique et de comprehension.
Les configurations sépcifiques sont décrites dans des fichiers à part. Par exemple la description d'un dépot yum.
Au lieu de faire figurer une interminable liste de fichiers (et donc devoir modifier le fichier de conf à chaque fois), on fait un include de tous les fichiers dans un dossier spécifique, que l'on nomme habituellement en .d (yum.repos.d).
Cela permet de rapidement déterminer dans le fichier de conf initial que c'est tout un dossier qui est inclu.

J'espere que cela répond à ta question.
Pour ceux que ça intéresse, j'ai posé la question ici ce soir, et les réponses sont variées : distributed, daemon, ou encore "c'est une convention, ça n'a pas d'explication"
Je vote aussi pour directory. Ca permet d'indiquer clairement que le fichier de config xxxx.conf fait appel au contenu du répertoire xxxx.d

A mon boulot, il y a plein de serveurs avec des répertoires en .d pour cette raison (indiquer un répertoire). Historiquement ces serveurs étaient avec un système sans la coloration syntaxique du ls. Ca permettait de faciliter la navigation dans l'arborescence.
Sans que ce soit explicitement précisé, l'expérience laisse penser qu'il s'agit d'une convention pour dénommer un répertoire où on stockera ce qui concerne le paquet dont le nom est celui du répertoire sans le d. Ce ne sont pas que des anciens fichiers de conf divisés. On a bien un yum.conf alors qu'on a un répertoire yum.repos.d
sinon .d sur un fichier c'est le code source d'un programme en D :hammer:
ok ok je -----> []
Bioinfornatics, j'adore ton trait d'esprit sur les sources de programme en D :lol:

Plus sérieusement, voici la raison qui m'a amené à me poser cette question sur le ".d" même si elle peut sembler futile.
J'ai rédigé quelques scripts en bash et en php qui utilisent des inclusions et des fichiers de configuration.
Comme c'est de l'automatisation de tâche purement perso (et parce que je faisais mes premières armes), j'ai un peu travaillé comme un cochon. C'est à dire que j'ai créé des répertoires, je les ai nommés un peu n'importe comment, j'ai pas mis assez de commentaires dans mes scripts, etc.

Bref, tout allait bien tant que tout ça était frais dans ma mémoire.

Suite à un renouvellement de matériel, j'ai récemment dû transporter ces scripts sur une nouvelle machine.
Et, là, j'ai évidemment eu quelques mauvaises surprises !

Pour ceux qui ont fonctionné directement, pas de problème...
Pour ceux qui ont coincé, je me suis rendu compte que l'absence d'une structure constante et cohérente avait sérieusement compliqué les choses (m'amenant à des relectures en profondeur).

Du coup, je me suis dit que je devais réorganiser tout ça.
Et il m'a paru évident qu'il était plus économique et plus logique de travailler suivant les conventions qui existent déjà plutôt que de développer mon propre système de conventions.


Plus spécifiquement, concernant les dossiers ".d", l'observation montre en effet que, le plus souvent, il s'agit de répertoires contenant des inclusions pour un fichier de configuration.
Nous devinons tous +/- le sens de la convention.

Pourquoi au-delà de son sens, je me suis interrogé sur son origine ?
C'est car au-delà du simple intérêt historique (qui à lui seul en vaut déjà la peine), savoir ce que le ".d" signifie, d'où ça vient, c'est une façon de fixer les choses dans sa mémoire.


De ce que je peux déjà lire comme réponses, j'ai le sentiment que cette convention a des origines multiples et qu'il y a eu des phénomènes d'imitations entre les différents projets et développeurs.

C'est une excellente idée, greg0ire que d'avoir posé la question sur un forum anglophone 😉

De l'ensemble des réponses à cet instant, j'ai le sentiment que "Distributed" et "Directory" soient les explications les plus rationnelles et les plus plausibles.

"Daemon" me semble plus douteux et me semble plutôt être une confusion avec une autre convention classique qui consiste à terminer le nom d'un exécutable par "d" lorsqu'il s'agit d'un démon (httpd, named... )

Merci à tous pour vos réponses !
Bonjour,

Pour moi la signification directory "n'a pas de sens" puisque la "nature" est précisé dans les propriétés (commande ls), je pencherais plutôt pour daemon car ces répertoires sont bien des répertoires contenant des fichiers de conf utilisé par des daemon (httpd, named, yum-updatesd etc...).
Pour ce qui est de distributed (qu'on pourrait traduire par partagé) c'est pas impossible mais à mon sens peux probable puisque, à part le deamon lui même et root, personne ne peux modifier le contenu du répertoire.
Ce n'est que mon opinion et je ne prétend pas détenir la vérité, tout comme Ambelliance je ne me suis pas poser la question car, pour moi, il était évidant que le .d était la pour deamon mais en voyant les réponses je me met à douter. Il faudrait peut être poser la question à quelqu'un de chez Red Hat voir même à Linus Torvald qui sais :-P l'un d'eux a peut être une réponse.
Ambelliance wrote:C'est une excellente idée, greg0ire que d'avoir posé la question sur un forum anglophone
Merci à toi pour ton excellente question, ça m'a value 7 upvotes pour l'instant!😉
Maxime Tierre wrote:Pour moi la signification directory "n'a pas de sens" puisque la "nature" est précisé dans les propriétés (commande ls), je pencherais plutôt pour daemon car ces répertoires sont bien des répertoires contenant des fichiers de conf utilisé par des daemon (httpd, named, yum-updatesd etc...).
Je pense que le but n'était pas de donner un sens particulier au répertoire, mais plutôt de pouvoir le créer.
Dans la réponse de jiliagre, on peut lire que dans des temps reculés, init se trouvait dans /etc et que l'impossibilité de créer un dossier init dans etc aurait fait ajouter le '.d' en question qui voudrait donc bien dire directory.
Pour moi ce serait donc plutôt
  1. directory
  2. daemon
  3. distributed