Unixパラダイムの1つが設定ファイルに設定名（プロパティ名とも呼ばれます）と設定値の両方を格納するのはなぜですか？
もう1つのアプローチは、KISS（Keep It Simple and Stupid）原則に従って、ファイル名に属性名を保存し、ファイル内に設定値のみを保存することです。プロファイルはまだフォルダを使用してソートできます。私が知る限り、同様のものはすでにLinuxの/ proc内のいくつかのファイルに実装されていますが、他の場所では見たことがありません。
私が知る限り、Unixの哲学は「すべてがファイルです」ということです。なぜここではない？
ベストアンサー1
構成ファイルがオプションで次の形式に分類されない理由についてのいくつかの考え方は次のとおりです。
config
default
key
key
...
key
other
key
key
...
最初のサブディレクトリは構成タイプであり、その中の各ファイル（ここで「キー」）はそれぞれファイルの内容である値を持つ別々の構成オプションです。もちろん、多くの例外を除いて、これらすべては私がこれまで学んだことです。
通常、ほとんどのUNIX / Linuxユーティリティは一度に1つのファイルで動作します。一行ずつ、複数のファイルの代わりに。なぜ？いくつかの理由がありますが、これが入力を処理する最も簡単な方法のようです。プログラミングインターフェイスで見ると、ほとんどのファイルは一連の行です。行（一部のテキストの後に
\nASCII改行文字が付く）は、実際にはファイルではなく、ほとんどのアプリケーションで最も基本的なデータ単位です。横に：端末は、ユーザーが作業するときに紙に1行ずつ印刷するように設計されています。正直なところ、ttyそれでもシリアルインターフェースと見なされるので、現代にはあまり変わりません。ソケットサーバーやその他のデーモンなどの複雑なプログラムの構成オプションが非常に多い状況を考えてみましょう。デフォルト値を取得するために何百ものファイルを開く必要がある潜在的に派生したプログラムには、開かれたファイル記述子の制限（簡単にバイパス）とファイルごとにいくつかのシステムコールという2つの罰があります。プログラムがカーネルにファイルの読み取りと開くの助けを求める必要があるため、システムコールが蓄積される可能性があります。
ed既存のエディタ（明らかに勝者です：D）sedまたはawk。多数のファイルベースの設定オプションで既存の編集ツールを使用することは本当に不便です。さらに、多数のオプションを検索することは、編集者にとって実際にできることではなく、ユーザーシェルの練習になります。ほとんどの設定オプションが単純な値である場合、echo一部のシェルIOリダイレクトはエディタの選択になります（ユーザーの好みを知っていれば悪くないかもしれません）。コメント。構成ファイルには、オプションよりも多くの説明が含まれている場合があります。本物コメントのように。設定ファイルを設定ディレクトリに置き換えて、突然そこに不快な行ベースのファイルがある場合、人々はreadmeファイルを作成することに慣れることをお勧めします。
全体として、ファイルベースの構成はUNIX / Linuxシステムの中核であると言いたいと思います。違うことができますか？確かに。現在のパラダイムが最善のアプローチですか？ UNIX / Linuxシステムでは機能できますが、ディレクトリ代替ファイルが入力インターフェースポイントである他の環境では機能しません。