.d는 디렉토리 이름에서 무엇을 의미합니까?

이름에 .d가있는 많은 디렉토리를 알고 있습니다.

init.d
yum.repos.d
conf.d

디렉토리를 의미합니까? 그렇다면 무엇을 명확히 하는가?

업데이트 : 그 .d의미 에 대해 많은 흥미로운 답변을 얻었지만 내 질문의 제목이 잘 선택되지 않았습니다. 나는 "의미"를 "의견"으로 바꿨다.

여기서 .d접미사는 디렉토리를 의미합니다. 물론 유닉스 파일 형식을 나타 내기 위해 접미사를 필요로하지 않기 때문에, 이것은 불필요 할 것입니다하지만 특정한 경우에, 뭔가 (명령 명확하게 할 필요가 있었다 /etc/init, /etc/rc0, /etc/rc1등) 그들이 (사용하는 디렉토리 /etc/init.d, /etc/rc0.d, /etc/rc1.d,를. ..)

이 규약은 최소한 Unix System V에서 도입되었지만 가능할 수도 있습니다. 이전에는 init명령이 /etc있었지만 현재는 /sbin최신 System V OS에 있습니다.

이 규칙은 단일 파일 구성 파일에서 단일 디렉토리에있는 여러 구성 파일로 이동하는 많은 응용 프로그램에서 채택되었습니다. 예를 들면 다음과 같습니다. /etc/sudoers.d

여기서 다시, 목표는 실행 파일과 구성 파일 사이가 아니라 이전의 모 놀리 식 구성 파일과 파일을 포함하는 디렉토리 사이의 이름 충돌을 피하는 것입니다.

데비안 메일 링리스트 에서 발췌 (강조 추가) :

배포 패키징이 점점 일반화되면서 여러 독립 패키지에서 제공하는 여러 조각으로 구성 파일을 형성하는 더 나은 방법이 필요하다는 것이 분명해졌습니다. 일부 공유 서비스를 구성해야하는 각 패키지는 다른 패키지에서 사용하는 공유 구성 파일을 편집하지 않고도 구성 만 관리 할 수 ​​있어야합니다.

가장 일반적으로 채택 된 규칙은 구성 파일로 가득 찬 디렉토리를 포함시키는 것입니다. 여기서 해당 디렉토리에 놓인 것은 활성화되고 해당 구성의 일부가됩니다. 이 규칙이 널리 보급됨에 따라 일반적으로 해당 디렉토리는 대체하거나 기능을 보강 한 구성 파일의 이름을 따서 명명되었습니다. 그러나 동일한 이름을 가진 디렉토리와 파일을 가질 수 없기 때문에 구별 할 방법이 필요하므로 구성 파일 이름 끝에 .d가 추가되었습니다. 따라서 구성 파일 / etc / Muttrc는 /etc/Muttrc.d의 조각으로 기능이 보강되고 / etc / bash_completion은 /etc/bash_completion.d/* 등으로 기능이 보강되었습니다. 때때로 /etc/xinetd.conf 또는 / etc / apache2 / conf를 보완하기 위해 /etc/xinetd.d와 같은 해당 규칙에 약간의 변형이 사용됩니다. d를 /etc/apache2/apache2.conf를 보충하십시오. 그러나 같은 기본 아이디어입니다.

일반적으로 * .d 규칙을 보면 "이것은 일부 서비스의 구성으로 병합 될 여러 구성 조각이 들어있는 디렉토리"를 의미합니다.

파트 2의 경우 ".d"의 이유 는 기본 구성 파일의 일부가 아니라 여전히 구성의 일부인 것처럼 "분배"된 것 입니다.

디렉토리 이름의 끝에 ".d"에 대해 말하면 이 대답 은 맞습니다. "디렉토리"에 대한 표시 일뿐입니다.

daemon 을 나타내는 "syslogd"와 같은 파일 이름과 "d"와 혼동하지 마십시오 . 백그라운드에서 실행중인 컴퓨터 프로세스

데몬의 부모 프로세스는 종종 초기화 프로세스 (PID = 1)입니다 (항상 그런 것은 아님). 프로세스는 일반적으로 하위 프로세스를 분기 한 다음 상위 프로세스를 즉시 종료하여 하위 프로세스를 채택하여 데몬이됩니다. 제어 tty에서 디먼 프로세스를 분리하는 것과 같이 다른 조작이 일반적으로 수행되므로 프로세스를 약간 단순화 한 것입니다. daemon (3)과 같은 편의 루틴이 일부 UNIX 시스템에 존재합니다.

디렉토리 자체를 의미하는 것은 아니며, 기본적으로 발생하는 것은 디렉토리로 끝나는 디렉토리 .d(일반적으로 단지 디렉토리 에만 있음 /etc)가 구성 부분을 차지 한다는 것입니다.

이것은 배포판에 예를 들어 범용 기본값을 포함하도록 설계 /etc/yum.conf되었지만 사용자 또는 다른 패키지가 자신의 yum 구성을 덮어 쓰지 않는 안전한 방법으로 추가하는 쉬운 방법이 있습니다.

m의 예로써 ...

RHEL5 또는 CentOS Box에서 EPEL 사용을 시작 하려면 기본 구성을 수정하거나 파일 충돌을 일으키지 않고 /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에 추가하면 /etc/httpd/conf/httpd.conf에 명시 적으로 추가 할 필요없이 Apache에서 파일을 읽습니다. 마찬가지로 chkconfig는 /etc/init.d의 파일에, cron 작업은 /etc/cron.d에 있습니다.

나는이 것을 생각하지만, 문서화 할 수 .d있는 디렉토리가와 연관되어 있음을 나타냅니다 D의 aemon.

증거는 이것이 적어도 그럴듯하다는 것을 나타냅니다.

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

^{_{거미줄 뒤의 내 마음의 뒤에서 아직도 고대 유닉스 역사의 작은 부분의 깊은 곳에서 어딘가에, 이것은 올바른 대답으로 저를 불러냅니다. 공룡이 죽기 전에 첫 포유류가 지구를 돌아 다니며 man페이지가 시스템에 보관되었을뿐만 아니라 발로 측정 된 선반에 물리적으로 보관 된 때부터 왔을 것입니다 .}}