Що означає .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). Процеси зазвичай стають демонами, примушуючи дочірній процес, а потім негайно закінчуючи процес батьків, тим самим спричиняючи ініт прийняти дочірній процес. Це дещо спрощене уявлення про процес, оскільки в основному виконуються інші операції, такі як відмежування демонового процесу від будь-яких контрольних tty. У деяких UNIX-системах для цієї мети існують звичайні програми, такі як демон (3).

Це не означає, що сам по собі каталог, в основному, те, що відбувається, полягає в тому, що каталоги, які закінчуються .d(зауважте, вони, як правило, існують /etc), займають конфігураційні частини.

Це розроблено так, що дистрибутив може включати, наприклад, універсальні параметри за замовчуванням /etc/yum.conf, але тоді користувачі чи інші пакети мають простий у використанні спосіб додавати власні конфігурації yum безпечним способом, який не буде перезаписаний.

Як приклад для 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, / тощо / є іншим прикладом) вказує, що містяться файли будуть прочитані та використані, часто для конфігурації, якщо вони відповідають заданий зразок і не вимагає явного додавання до якогось основного списку.

Отже, якщо ви додаєте файли форми * .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вказує на те, що каталог асоціюється з d aemon.

Докази свідчать про те, що це принаймні правдоподібно:

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

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