Что означает .d в именах каталогов?

Я знаю много каталогов с именем .d:

init.d
yum.repos.d
conf.d

Это значит каталог? Если да, то с чем это связано?

ОБНОВЛЕНИЕ: у меня было много интересных ответов о том, что .dозначает, но название моего вопроса не было правильно выбрано. Я изменил «значит» на «стоять».

.dСуффикс здесь означает каталог. Конечно, это было бы ненужным , поскольку Unix не требует суффикса для обозначения типа файла , но в этом конкретном случае, что - то необходимо было неоднозначность команды ( /etc/init, /etc/rc0, /etc/rc1и так далее) и каталогов , которые они используют ( /etc/init.d, /etc/rc0.d, /etc/rc1.d,. ..)

Это соглашение было введено, по крайней мере, в Unix System V, но, возможно, ранее. initКоманда используется для размещения в , /etcно , как правило , в настоящее время /sbinна современных System V операционки.

Обратите внимание, что это соглашение было принято многими приложениями, переходящими из одного файла конфигурации файла в несколько файлов конфигурации, расположенных в одном каталоге, например: /etc/sudoers.d

Здесь опять-таки цель состоит в том, чтобы избежать конфликта имен не между исполняемым файлом и файлом конфигурации, а между бывшим монолитным файлом конфигурации и каталогом, в котором они содержатся.

Выдержка из списка рассылки Debian (выделение добавлено):

Когда дистрибутивная упаковка стала все более распространенной, стало ясно, что нам нужны лучшие способы формирования таких файлов конфигурации из нескольких фрагментов, часто предоставляемых несколькими независимыми пакетами. Каждый пакет, которому необходимо настроить какую-либо общую службу, должен иметь возможность управлять только своей конфигурацией без необходимости редактирования общего файла конфигурации, используемого другими пакетами.

Наиболее распространенным принятым соглашением было разрешить включение каталога, полного файлов конфигурации, когда все, что помещено в этот каталог, станет активным и частью этой конфигурации. Поскольку это соглашение стало более распространенным, этот каталог обычно назывался в честь файла конфигурации, который он заменял или дополнял. Но поскольку нельзя иметь каталог и файл с одинаковым именем, для различения требовался какой-то метод, поэтому .d был добавлен в конец имени файла конфигурации. Следовательно, файл конфигурации / etc / Muttrc был дополнен фрагментами в /etc/Muttrc.d, файл / etc / bash_completion дополнен файлом /etc/bash_completion.d/* и так далее. Иногда используются небольшие изменения в этом соглашении, такие как /etc/xinetd.d для дополнения /etc/xinetd.conf или / etc / apache2 / conf. d дополнить /etc/apache2/apache2.conf. Но это та же самая основная идея.

Обычно, когда вы видите это * .d соглашение, это означает, что «это каталог, содержащий кучу фрагментов конфигурации, которые будут объединены в конфигурацию для некоторого сервиса».

Для части 2, причина для «.d», моя лучшая догадка будет «распределена», как не в основном файле конфигурации, а в части конфигурации .

Если вы говорите о «.d» в конце имен каталогов, этот ответ правильный, это просто маркер для «каталогов».

Только не путайте его с «d» в имени и имени файла, например «syslogd», что означает « демон» . Компьютерный процесс работает в фоновом режиме.

родительский процесс демона часто (но не всегда) является процессом init (PID = 1). Процессы обычно становятся демонами, разветвляя дочерний процесс, а затем немедленно завершая его родительский процесс, в результате чего init принимает дочерний процесс. Это несколько упрощенное представление о процессе, поскольку обычно выполняются другие операции, такие как отделение процесса-демона от любого управляющего tty. Для этой цели в некоторых системах UNIX существуют удобные процедуры, такие как daemon (3).

Это не означает, что каталоги сами по себе, в основном происходит то, что каталоги, которые заканчиваются .d(обратите внимание, что они обычно только когда-либо /etc), занимают части конфигурации.

Это разработано так, чтобы дистрибутивы могли включать в себя универсальные значения по умолчанию, например /etc/yum.conf, но тогда есть простой в использовании метод для пользователей или других пакетов для добавления их собственных конфигураций yum безопасным способом, который не будет перезаписан.

Как пример для ням ...

Если я хочу начать использовать EPEL на своем RHEL5 или CentOS Box, я могу настроить новый репозиторий в /etc/yum.repos.dпапке (скажем /etc/yum.repos.d/epel.repo) или установить пакет epel-release, который автоматически создает файл, не изменяя конфигурацию по умолчанию и не вызывая конфликты файлов, которые не должно случиться

Что произойдет, так это то, что большинство программ прочитают свою конфигурацию по умолчанию ( /etc/yum.confнапример), а затем переберут свои .dпапки, включая фрагменты конфигурации, в работающую программу.

Надеюсь, это объясняет это для вас.

Точно так же, как файлы могут .extуказывать тип файла (обычно называемый «расширением»), каталоги иногда должны .dпоказывать, что это каталог, а не файл. Это его тип. lsВывод по умолчанию визуально не различает каталоги и файлы, так что .dэто просто старое соглашение, показывающее его тип (каталог) в таких списках.

В более общем смысле, каталоги .d (другой пример - /etc/httpd/conf.d, /etc/rc.d, / etc /) указывают, что содержащиеся в них файлы будут читаться и использоваться, часто для конфигурации, если они совпадают. данный шаблон и не требует явного добавления в какой-либо основной список.

Поэтому, если вы добавите файлы вида * .repo в /etc/yum.repos.d, yum будет использовать их при запуске, не добавляя их в список конфигураций /etc/yum.conf. Если вы добавите файлы вида * .conf в /etc/http/conf.d, они будут прочитаны Apache без необходимости явного добавления в /etc/httpd/conf/httpd.conf. Аналогично, chkconfig для файлов в /etc/init.d, cron заданий в /etc/cron.d.

Я думаю, но не может документально подтвердить, что .dуказывает на то, что каталог , связанный с д aemon.

Доказательства указывают на то, что это по крайней мере правдоподобно:

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

^{_{Где-то в глубоких зарослях маленьких кусочков древней истории Unix, все еще гремящих в глубине моего сознания за паутиной, это вызывает у меня правильный ответ. Я полагаю, что это могло произойти со времени, когда первые млекопитающие бродили по земле, прежде чем динозавры начали вымирать, и manстраницы были не только в системе, но и физически в стойках, измеряемых ногой.}}