回答:
.dディレクトリを表します。これは、ディレクトリベースの構成を単一の構成ファイルに基づく構成と区別するための規則です。多くの場合、たとえば/etc/logrotate.confとのように、両方の機能を利用できます/etc/logrotate.d/。
また、通常、このようなディレクトリ内のすべての（合理的に名前が付けられた）ファイルが自動的に1つの構成に結合されます。パッケージは、そのようなディレクトリにファイルをインストールでき、自動的に使用されます。再び、/etc/logrotate.d/良い例です。対照的に、最後に終わらない構成ファイルのディレクトリには、.dおそらく同じパッケージに属する構成ファイルのランダムな照合が含まれており、それらの処理方法について何も推測できません（例）/etc/zsh/。
ピーターの答えを少し拡張するために、この.dパターンは、構成ファイルのより簡単な追加と削除を可能にします。特定の.dプログラムの場合、管理者は、編集することなく、ファイルを.dディレクトリに単にコピーまたは削除できます。既存の構成ファイル。
たとえば、システムにcronジョブを追加したい場合、お気に入りのテキストエディターを使用して、新しいスケジュールされたジョブで/ etc / crontabを編集できます。これは単一のサーバーまたは少数のサーバーでは問題ありませんが、データセンター/クラウド環境で作業している場合は、100台のサーバーで実行してみてください。後者の場合、一時ファイルを使用したsedやexなどのツールを使用してファイルを適切な場所に書き込むことができますが、コマンドを適切に作成していない場合は、少しリスクがあります。実際、これらの編集コマンドのタイプミスが原因で、構成ファイルが完全に削除されているのを見てきました。
それを、スケジュールされたジョブを含むファイルを/etc/cron.dに配置することと比較してください。ファイルをそこにコピーするだけで、次にcronが実行されるとき（通常は毎分）、新しいファイルが表示され、それに応じてソース/処理されます。これは、独自のパッケージをロールバックしたい場合にPeterが述べたようにすばらしいです。/etc/cron.dファイルは、インストールされるパッケージアーカイブ内の別のファイルです。パッケージを削除すると、cron.dファイルが削除され、cronは実行されなくなります。
最後に、.dディレクトリを持つすべてのプログラムには、インクルードの順序や構成の上書きなど、ファイルのソース方法に関する限り、独自の実装がある場合があります。したがって、ファイルを.dディレクトリに配置することを決定したときは常に、それが目的どおりに機能することを常に確認し、.dディレクトリを持つ別のプログラムの場合と同様に機能すると想定しないでください。