이름에 .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페이지가 시스템에 보관되었을뿐만 아니라 발로 측정 된 선반에 물리적으로 보관 된 때부터 왔을 것입니다 .
