.dはディレクトリ名で何を表していますか？
名前に.dが含まれる多くのディレクトリを知っています。
init.d
yum.repos.d
conf.d
ディレクトリを意味しますか？はいの場合、これから何が明確になりますか？
PDATE：.dという意味ですが、私の質問のタイトルが適切に選択されていません。 「平均」を「〜」に変更しました。
ここでの.dサフィックスはディレクトリを意味します。もちろん、Unixではファイルタイプを示すためのサフィックスが必要ないため、これは不要ですが、その特定のケースでは、コマンドを明確にするために何かが必要でした（/etc/init、/etc/rc0、/etc/rc1など）およびそれらが使用するディレクトリ（/etc/init.d、/etc/rc0.d、/etc/rc1.d、...）
この規則は、少なくともUnix System Vで導入されましたが、おそらくそれ以前に導入されました。 initコマンドは、以前は/etcにありましたが、最近のSystem V OSでは一般に/sbinになりました。
この規則は、単一のファイル構成ファイルから単一のディレクトリにある複数の構成ファイルに移動する多くのアプリケーションで採用されていることに注意してください。例：/etc/sudoers.d
ここでも、目標は、実行可能ファイルと構成ファイルの間ではなく、以前のモノリシック構成ファイルとそれらを含むディレクトリの間の名前の衝突を回避することです。
Debianメーリングリスト からの抜粋（強調を追加）：
配布パッケージがますます一般的になると、複数の独立したパッケージによってしばしば提供される複数のフラグメントからそのような構成ファイルを形成するより良い方法が必要であることが明らかになりました。いくつかの共有サービスを構成する必要がある各パッケージは、他のパッケージで使用される共有構成ファイルを編集する必要なく、その構成のみを管理できる必要があります。
採用された最も一般的な規則は、構成ファイルでいっぱいのディレクトリを含めることを許可することでした。そのディレクトリにドロップされたものはすべてアクティブになり、その構成の一部になります。その規則が広く普及するにつれ、そのディレクトリは通常、置換または拡張された構成ファイルにちなんで名付けられました。ただし、同じ名前のディレクトリとファイルを持つことはできないため、区別するためにいくつかの方法が必要だったため、構成ファイル名の末尾に.dを追加しました。したがって、構成ファイル/ etc/Muttrcは/etc/Muttrc.d内のフラグメントによって拡張され、/ etc/bash_completionは/etc/bash_completion.d/*などで拡張されました。 /etc/xinetd.confを補足する/etc/xinetd.dや/etc/Apache2/Apache2.confを補足する/etc/Apache2/conf.dなど、その規則のわずかなバリエーションが使用される場合があります。しかし、それは同じ基本的な考え方です。
一般に、*。dの規則が表示される場合、これは「これは、いくつかのサービスの構成にマージされる構成フラグメントの束を保持するディレクトリです」
パート2の ".d"の理由は、のように、メインの構成ファイルの一部ではなく、構成の一部である 。
ディレクトリ名の最後にある「.d」について話すと、 この答え が正しいです。これは、「ディレクトリ」の単なるマーカーです。
daemon を表す「syslogd」のように、ファイル名の「d」と混同しないでください。バックグラウンドで実行されているコンピュータープロセス。
デーモンの親プロセスは、多くの場合（常にではない）initプロセス（PID = 1）です。プロセスは通常、子プロセスをforkし、親プロセスをすぐに終了させることでデーモンになり、initに子プロセスを採用させます。これは、デーモンプロセスと制御ttyの関連付けを解除するなど、他の操作が一般的に実行されるため、プロセスを多少簡略化したものです。そのため、一部のUNIXシステムには、daemon（3）などの便利なルーチンが存在します。
これはディレクトリ自体を意味するのではなく、基本的には.dで終わるディレクトリです（これらは通常/etcでのみであることに注意してください）。構成パーツを使用します。
これは、ディストリビューションがたとえば/etc/yum.confにユニバーサルデフォルトを含めることができるように設計されていますが、ユーザーまたは他のパッケージが、上書きされない安全な方法で独自のyum設定を追加する簡単な方法があります。
Yumの例として...
RHEL5またはCentOSボックスで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/being別の例）は、含まれているファイルが読み取られて使用されることを示します。与えられたパターンで、いくつかのマスターリストに明示的に追加する必要はありません。
したがって、*。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エモン。
証拠はこれが少なくとももっともらしいことを示します：
Sudo find / -maxdepth 3 -name "*.d"
クモの巣の後ろの私の心の後ろでまだ古代Unixの歴史の少しの深いくぼみのどこかにまだガタガタ音を立てて、これは正しい答えとして私に呼びかけます。それは恐竜が絶滅し始める前に最初の哺乳類が地球を歩き回り、manページがシステム上に保持されただけでなく、足によって測定されたラックに物理的に保持されていた時期から来たと思われます。