Co oznacza .d w nazwach katalogów?

118

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ć”.

greg0ire
źródło
9
Pochodzenie .dznajduje się w komentarzu msw do tego powiązanego pytania w Ask Ubuntu .
Gilles
@Gilles, ha, myślałem, że to później niż System-V, ale tak, nawet wciąż nie ma znaczenia, aby „.d” zostało wybrane z tego, co mogę powiedzieć.
NJ
@Gilles: ciekawe, wydaje się, że odpowiedź brzmi: wyjaśnienie zaginęło ... zgodnie z pierwszym komentarzem do pierwszej odpowiedzi w twoim linku
greg0ire,
Nie wiem, dlaczego .dsię init.d, ale to wydaje się prawie wszystkie niestandardowe pliki konfiguracyjne przejść do .dkatalogów w RHEL / CentOS / Fedory.
LiuYan 研 研
@Liu Yan - Rzeczywiście, nie mogłem tego wyjaśnić w żaden sposób, który można by interpretować jako spójny.
Tim Post

Odpowiedzi:

102

.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.

jlliagre
źródło
4
+1, myślę, że masz rację, ale jak dotąd nikt nie podał żadnego cytatu dla jego teorii
greg0ire
Myślę, że to raczej konwencja, która wyrosła na ludziach, niż faktyczny wyraźny standard
Shadur,
1
Kiedy wykonujesz lspolecenie (nie ls -al) bez użycia --coloropcji (wyraźnie określonej lub części LS_OPTIONSzmiennej środowiskowej), posiadanie „.d” wyróżnia katalogi na liście. Dlatego zawsze myślałem, że to zrobione.
LawrenceC
^ colornie jest jedynym lub najlepszym sposobem wizualnego oflagowania katalogów. ls -Fzrobi to i wiele innych przydatnych rzeczy.
underscore_d
56

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 .

E-man
źródło
8
Zaskakujące ... Myślałem, że to przemawia na korzyść „katalogu”, co oznacza „jest to katalogowa część konfiguracji”.
greg0ire,
2
To oczywiste. Dlaczego ktoś to przeczytałby i stwierdził, że .dcokolwiek innego znaczyło poza mną! Ale to źródło pokazuje tylko uzasadnienie Debiana dla, w jednym kontekście, zastosowania konwencji, która istniała od pierwszych dni istnienia Uniksa. Zastanawiam się, czy ten opiekun Debiana celowo uprościł - czy naprawdę myślał, że Debian wynalazł tę praktykę.
underscore_d
11

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).

Philomath
źródło
Nie bardzo, to są nazwy katalogów.
Keith,
@Keith: ups, błędnie myślałem, że mówi o plikach kończących się na „d” syslogd, a nie katalogach kończących się na „.d”. Wkrótce dokonam edycji.
Philomath
To, co myślałem, ale widzę, że często używany w katalogach konfiguracyjnych dla programów, które nie daemonize, np sysctl.d, modprobe.d.. byłoby to niewłaściwe wykorzystanie?
Tim Post
@Tim Post: zobacz powyższe 2 komentarze (i odpowiedź Keitha), wkrótce zmienię moją odpowiedź.
Philomath
Edytowane (15 chr)
Philomath
4

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.

NJ
źródło
+1, to wiele wyjaśnia, ale ... nie wybór litery „d”.
greg0ire,
1
Czy musi istnieć wyjaśnienie wyboru? Jest to tylko konwencja, która rozwinęła się z czasem, nie jest (z szybkiego spojrzenia) zdefiniowana w FHS, ale może być zawarta w standardzie LSB. Cron był jednym z pierwszych, jak pamiętam. (Edytuj: w rzeczywistości byłby to init)
NJ
3

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.

Keith
źródło
6
Ponadto .dsufiks zapobiega kolizjom z plikiem o podobnej nazwie. Na przykład możesz mieć plik konfiguracyjny /etc/apt/sources.listi katalog plików konfiguracyjnych /etc/apt/sources.list.d.
jmtd
2
^ Chciałbym powiedzieć, że nie jest to „dodatek”, ale przede wszystkim powód zjazdu. Unix / Linux nigdy nie był cenny w konieczności dodawania rozszerzeń do rzeczy, szczególnie na początku, więc wątpię, żeby to było bez uzasadnionego powodu.
underscore_d
2

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.

Tim
źródło
+1, ale ... taka sama uwaga jak wyżej.
greg0ire,
1
@greg: Ze względu na różnorodność sposobów sortowania odpowiedzi „powyżej” i „poniżej” są kiepskimi sposobami odwoływania się do (komentowania) innych odpowiedzi. „Najstarsze” i „najnowsze” rodzaje mają przeciwne znaczenia dla takich opisów opartych na pozycji, a podczas sortowania według „głosów” względne położenie dwóch odpowiedzi może z czasem ulec zmianie.
Chris Johnsen
@Chris Johnsen: właśnie to sobie uświadomiłem, ale za późno. Miałem na myśli mój komentarz do odpowiedzi NJ.
greg0ire,
1

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ą.

Dennis Williamson
źródło
+1 za majaczenie na końcu, ale myślę, że to nie pasuje do yum.repos.d ...
greg0ire,
</cobwebs>Uważam, że odpowiedzi wskazujące, że celem .djest ujednoznacznienie katalogu z powiązanych i podobnie nazwanych plików, są poprawne. Poparłem głos E-mana i Jlliagre'a.
Dennis Williamson
Pytanie brzmi: „co oznacza„ .d ”” i otrzymałem mnóstwo wyjaśnień dotyczących powodu, dla którego jest to „.d”, ale w kilku, które udzieliły odpowiedzi dotyczącej znaczenia, nie podano żadnego źródła. Osobiście myślę, że to oznacza katalog.
greg0ire,
1
yumjest nowszym wynalazkiem.
Dennis Williamson