O que o .d representa nos nomes de diretório?

Conheço muitos diretórios com .d em seu nome:

init.d
yum.repos.d
conf.d

Isso significa diretório? Se sim, do que isso desambigua?

ATUALIZAÇÃO: Tive muitas respostas interessantes sobre o que .dsignifica, mas o título da minha pergunta não foi bem escolhido. Eu mudei "mean" para "stand for".

O .dsufixo aqui significa diretório. Claro, isso seria desnecessário como Unix não requer um sufixo para designar um tipo de arquivo, mas, nesse caso específico, algo era necessário para disambiguate os comandos ( /etc/init, /etc/rc0, /etc/rc1e assim por diante) e os diretórios que eles usam ( /etc/init.d, /etc/rc0.d, /etc/rc1.d,. ..)

Esta convenção foi introduzida pelo menos com o Unix System V, mas possivelmente anteriormente. O initcomando costumava estar localizado, /etcmas geralmente está agora nos /sbinsistemas operacionais modernos do System V.

Observe que esta convenção foi adotada por muitos aplicativos que se deslocam de um único arquivo de configuração de arquivo para vários arquivos de configuração localizados em um único diretório, por exemplo: /etc/sudoers.d

Aqui, novamente, o objetivo é evitar o conflito de nomes, não entre o arquivo executável e o arquivo de configuração, mas entre o antigo arquivo de configuração monolítico e o diretório que os contém.

Trecho de uma lista de discussão Debian (ênfase adicionada):

Quando o empacotamento de distribuição se tornou cada vez mais comum, ficou claro que precisávamos de melhores maneiras de formar esses arquivos de configuração a partir de vários fragmentos, geralmente fornecidos por vários pacotes independentes. Cada pacote que precisa configurar algum serviço compartilhado deve poder gerenciar apenas sua configuração sem precisar editar um arquivo de configuração compartilhado usado por outros pacotes.

A convenção mais comum adotada foi permitir a inclusão de um diretório cheio de arquivos de configuração, onde qualquer coisa inserida nesse diretório se tornaria ativa e faria parte dessa configuração. À medida que essa convenção se generalizava, esse diretório geralmente era nomeado após o arquivo de configuração que estava substituindo ou aumentando. Mas como não se pode ter um diretório e um arquivo com o mesmo nome, foi necessário distinguir algum método, portanto, .d foi anexado ao final do nome do arquivo de configuração. Portanto, um arquivo de configuração / etc / Muttrc foi aumentado por fragmentos em /etc/Muttrc.d, / etc / bash_completion foi aumentado com /etc/bash_completion.d/* e assim por diante. Às vezes, pequenas variações nessa convenção são usadas, como /etc/xinetd.d para complementar /etc/xinetd.conf ou / etc / apache2 / conf. d para complementar o /etc/apache2/apache2.conf. Mas é a mesma ideia básica.

Geralmente, quando você vê essa convenção * .d, significa "este é um diretório que contém vários fragmentos de configuração que serão mesclados na configuração de algum serviço".

Para a parte 2, o motivo do ".d", meu melhor palpite seria "distribuído", como não faz parte do arquivo de configuração principal, mas ainda faz parte da configuração .

Se você falar sobre ".d" no final dos nomes de diretório, esta resposta está correta, é apenas um marcador para "diretório".

Apenas não confunda com "d" no e de um nome de arquivo, como "syslogd", que significa daemon . Um processo de computador em execução em segundo plano.

o processo pai de um daemon é frequentemente (mas nem sempre) o processo init (PID = 1). Os processos geralmente se tornam daemons, criando um processo filho e forçando o processo pai a sair imediatamente, fazendo com que o init adote o processo filho. Essa é uma visão um pouco simplificada do processo, já que outras operações geralmente são executadas, como dissociar o processo daemon de qualquer controle tty. Rotinas de conveniência como o daemon (3) existem em alguns sistemas UNIX para esse fim.

Isso não significa diretório propriamente dito, basicamente o que está acontecendo é que os diretórios que terminam em .d(observe que esses geralmente são apenas sempre /etc) recebem partes da configuração.

Isso foi desenvolvido para que as distribuições possam incluir padrões universais, por exemplo /etc/yum.conf, mas existe um método fácil de usar para usuários ou outros pacotes anexarem suas próprias configurações yum de uma maneira segura que não será substituída.

Como um exemplo para yum ...

Se eu quiser começar a usar o EPEL no meu RHEL5 ou CentOS Box, posso configurar um novo repositório na /etc/yum.repos.dpasta (por exemplo /etc/yum.repos.d/epel.repo) ou instalar o pacote epel-release que cria o arquivo automaticamente, sem modificar minha configuração padrão ou causar conflitos de arquivo que não precisa acontecer.

O que acontecerá é que a maioria dos programas lê sua configuração padrão ( /etc/yum.confpor exemplo) e depois itera sobre suas .dpastas, incluindo trechos de configuração no programa em execução.

Espero que isso explique para você.

Assim como os arquivos podem precisar .extespecificar que tipo de arquivo é (geralmente chamado de "extensão"), os diretórios às vezes precisam .dmostrar que é um diretório e não um arquivo. Esse é o seu tipo. A lssaída padrão não diferencia visualmente diretórios e arquivos; portanto, .dé apenas uma convenção antiga para mostrar seu tipo (diretório) nessas listagens.

De maneira mais geral, os diretórios .d (/etc/httpd/conf.d, /etc/rc.d, / etc / sendo outro exemplo) indicam que os arquivos contidos serão lidos e usados, geralmente para configuração, se corresponderem um determinado padrão e não exigem a inclusão explícita em alguma lista mestre.

Portanto, se você adicionar arquivos do formato * .repo ao /etc/yum.repos.d, o yum o utilizará durante a execução sem precisar adicioná-lo a uma lista de configurações /etc/yum.conf. Se você adicionar arquivos do formato * .conf ao /etc/http/conf.d, eles serão lidos pelo Apache sem precisar serem explicitamente adicionados ao /etc/httpd/conf/httpd.conf. Da mesma forma, chkconfig para arquivos em /etc/init.d, tarefas cron em /etc/cron.d.

Eu acho, mas não pode documentar, que o .dindica que o diretório está associado a um d Aemon.

As evidências indicariam que isso é pelo menos plausível:

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

^{_{Em algum lugar nos recônditos profundos dos pedacinhos da história antiga do Unix ainda rondando no fundo da minha mente atrás das teias de aranha, isso me chama como a resposta correta. Acredito que pode ter ocorrido em uma época em que os primeiros mamíferos vagavam pela Terra antes que os dinossauros começassem a desaparecer e as manpáginas não só eram mantidas no sistema, mas também fisicamente nas prateleiras medidas pelo pé.}}