Co oznacza .d w nazwach katalogów?

Znam wiele katalogów z rozszerzeniem .d w ich nazwie:

init.d
yum.repos.d
conf.d

Czy to oznacza katalog? Jeśli tak, to z czego to jednoznacznie wynika?

AKTUALIZACJA: Miałem wiele interesujących odpowiedzi na temat tego, co to .dznaczy, ale tytuł mojego pytania nie został dobrze wybrany. Zmieniłem „znaczy” na „oznaczać”.

.dPrzyrostek oznacza tu katalog. Oczywiście, byłoby to niepotrzebne, gdyż nie wymaga Unix przyrostek oznaczający typ pliku, ale w tym konkretnym przypadku, coś trzeba było dwuznaczności poleceń ( /etc/init, /etc/rc0, /etc/rc1i tak dalej) i katalogów używają ( /etc/init.d, /etc/rc0.d, /etc/rc1.d,. ..)

Konwencję tę wprowadzono przynajmniej w systemie Unix System V, ale prawdopodobnie wcześniej. initPolecenie używane do umieszczenia w /etcale ogólnie jest teraz w /sbinnowoczesnych systemów operacyjnych System V.

Należy zauważyć, że ta konwencja została przyjęta przez wiele aplikacji przechodzących z jednego pliku konfiguracyjnego do wielu plików konfiguracyjnych znajdujących się w jednym katalogu, np .: /etc/sudoers.d

Tutaj znowu celem jest uniknięcie kolizji nazw, nie między plikiem wykonywalnym a plikiem konfiguracyjnym, ale między poprzednim monolitycznym plikiem konfiguracyjnym a katalogiem zawierającym je.

Fragment listy mailingowej Debiana (wyróżnienie dodane):

Kiedy opakowania dystrybucyjne stały się coraz bardziej powszechne, stało się jasne, że potrzebujemy lepszych sposobów tworzenia takich plików konfiguracyjnych z wielu fragmentów, często dostarczanych przez wiele niezależnych pakietów. Każdy pakiet, który musi skonfigurować niektóre usługi współdzielone, powinien móc zarządzać tylko swoją konfiguracją bez konieczności edytowania pliku konfiguracji współdzielonej używanego przez inne pakiety.

Najczęstszą przyjętą konwencją było zezwolenie na włączenie katalogu pełnego plików konfiguracyjnych, w którym wszystko, co spadnie do tego katalogu, stanie się aktywne i będzie częścią tej konfiguracji. Ponieważ konwencja ta stała się bardziej rozpowszechniona, katalog ten zwykle nosił nazwę pliku konfiguracyjnego, który zastępuje lub rozszerza. Ale ponieważ nie można mieć katalogu i pliku o tej samej nazwie, do rozróżnienia potrzebna była jakaś metoda, dlatego na końcu nazwy pliku konfiguracyjnego dodano .d. Dlatego plik konfiguracyjny / etc / Muttrc został rozszerzony o fragmenty w /etc/Muttrc.d, / etc / bash_completion został rozszerzony o /etc/bash_completion.d/* i tak dalej. Czasami stosuje się niewielkie zmiany tej konwencji, takie jak /etc/xinetd.d w celu uzupełnienia /etc/xinetd.conf lub / etc / apache2 / conf. d, aby uzupełnić /etc/apache2/apache2.conf. Ale to ten sam podstawowy pomysł.

Zasadniczo, gdy zobaczysz tę konwencję * .d, oznacza to, że „jest to katalog zawierający kilka fragmentów konfiguracji, które zostaną połączone w konfigurację dla niektórych usług”.

Jeśli chodzi o część 2, przyczynę „.d”, to moje przypuszczenie byłoby „rozproszone”, ponieważ nie jest to część głównego pliku konfiguracyjnego, ale nadal część konfiguracji .

Jeśli mówisz o „.d” na końcu nazw katalogów, ta odpowiedź jest słuszna, to tylko znacznik „katalogów”.

Po prostu nie myl go z „d” na końcu nazwy pliku, np. „Syslogd”, co oznacza demona . Proces komputerowy uruchomiony w tle.

proces nadrzędny demona jest często (ale nie zawsze) procesem inicjującym (PID = 1). Procesy zwykle stają się demonami przez rozwidlenie procesu potomnego, a następnie natychmiastowe zakończenie procesu macierzystego, co powoduje, że init przyjmuje proces potomny. Jest to nieco uproszczony widok procesu, ponieważ generalnie wykonywane są inne operacje, takie jak oddzielanie procesu demona od dowolnego kontrolującego urządzenia. W tym celu w niektórych systemach UNIX istnieją procedury wygody, takie jak demon (3).

Nie oznacza to katalogu jako takiego, w zasadzie dzieje się tak, że katalogi, które kończą się na .d(pamiętaj, że zwykle są tylko w środku /etc), biorą części konfiguracyjne.

Zostało to zaprojektowane tak, aby dystrybucje mogły zawierać na przykład uniwersalne ustawienia domyślne /etc/yum.conf, ale istnieje też łatwa w użyciu metoda dla użytkowników lub innych pakietów, aby bezpiecznie dołączyć własne konfiguracje yum w bezpieczny sposób, który nie zostanie nadpisany.

Jako przykład dla mniam ...

Jeśli chciałbym zacząć korzystać z EPEL na moim RHEL5 lub CentOS Box, mogę skonfigurować nowe repozytorium w /etc/yum.repos.dfolderze (powiedzmy /etc/yum.repos.d/epel.repo) lub zainstalować pakiet epel-release, który tworzy plik automatycznie, bez modyfikowania mojej domyślnej konfiguracji ani powodowania konfliktów plików, które nie musi się zdarzyć.

Co się stanie, większość programów przeczyta swoją domyślną konfigurację ( /etc/yum.confna przykład), a następnie przejdzie przez .dfoldery, w tym fragmenty konfiguracji do uruchomionego programu.

Mam nadzieję, że to ci wyjaśni.

Podobnie jak pliki mogą .extokreślać typ pliku (zwykle nazywany „rozszerzeniem”), katalogi czasami muszą .dpokazywać, że jest to katalog, a nie plik. To jest ten typ. Domyślne lswyjście nie wizualnie różnicuje katalogów i plików, więc .djest to tylko stara konwencja pokazująca swój typ (katalog) na takich listach.

Mówiąc bardziej ogólnie, katalogi .d (/etc/httpd/conf.d, /etc/rc.d, / etc / są kolejnym przykładem), wskazują, że zawarte pliki zostaną odczytane i wykorzystane, często do konfiguracji, jeśli są zgodne dany wzorzec i nie wymagają jawnego dodawania do niektórych list głównych.

Więc jeśli dodasz pliki w postaci * .repo do /etc/yum.repos.d, yum użyje go podczas uruchamiania bez potrzeby dodawania go do listy konfiguracji /etc/yum.conf. Jeśli dodasz pliki w postaci * .conf do /etc/http/conf.d, zostaną one odczytane przez Apache bez konieczności jawnego dodawania do /etc/httpd/conf/httpd.conf. Podobnie, chkconfig do plików w /etc/init.d, zadania cron w /etc/cron.d.

Myślę, ale nie mogę udokumentować, że .dwskazuje, że katalog jest powiązany z demonem d .

Dowody wskazują, że jest to co najmniej prawdopodobne:

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

^{_{Gdzieś w głębokich zakamarkach małych fragmentów starożytnej historii uniksowej wciąż grzechotających w moich myślach za pajęczynami, to woła mnie jako prawidłową odpowiedź. Myślę, że mogło to pochodzić z czasów, gdy pierwsze ssaki wędrowały po ziemi, zanim dinozaury zaczęły wymierać, a manstrony były nie tylko trzymane w systemie, ale także fizycznie w stojakach mierzonych stopą.}}