/etc/profile.dのスクリプトは何をしますか？

これらのファイルがBashの起動にも重要である場合、なぜ/ etc / profileの一部ではないのですか？

「なぜそれらを1つの巨大なスクリプトに結合しないのですか？」を意味する場合、答えは次のようになります。

1. なぜなら、スクリプトを担当する人にとっては、メンテナンスが悪夢になるからです。
2. スクリプトを独立したモジュールにロードすると、システム全体がより動的に調整されるため、他のスクリプトに影響を与えることなく個々のスクリプトを追加および削除できます。など。
3. /etc/profileを介してロードされるため、同じ方法でbash "プロファイル"の一部になります。

これらのファイルがBashの起動に重要ではないアプリケーション固有の起動ファイルである場合、なぜ起動プロセスの一部ですか？設定を含む特定のアプリケーションが実行されたときにのみ実行されないのはなぜですか？

私の考えでは、これはより広いデザイン哲学に関する質問なので、2つに分けてみましょう。最初の質問は、シェル環境の使用の価値と適切性に関するものです。肯定的な価値がありますか？はい、便利です。すべての構成問題に最適なソリューションですか？いいえ、しかし単純なパラメータを管理するのに非常に効果的であり、広く認識され理解されています。対照的に、これらのものを異機種別に構成することを決定した場合、$ PATHは独立したスタンドアロンツールとして管理でき、優先ツール（$EDITORなど）はsqliteファイルのどこかにあり、$ LC langエントリはsqliteファイルに存在する可能性があります。場所などで異なるカスタム形式を使用します。環境変数だけを使用し、/etc/profile.d突然もっと単純に見えませんか？環境変数の5つの共通点を理解するために、まったく異なる5つのメカニズムを学ぶのではなく、環境変数が何であるか、どのように機能し使用するかをすでに知っています。名前を適切に指定してください。「環境」。

2番目の質問は「スタートアップは適切な時期ですか？」で、それほど効率的ではない（使用することも使用しないかもしれないすべてのデータなど）反論を提起する。しかし：

• 実際にはそれほど多くのデータではありません。部分的には、正しい考えを持つ人がいくつかの単純なパラメータを処理するためにデータを使用しないためです（アプリケーションを構成する他の方法があるため）。
• 賢明に使用する場合は、頻繁に呼び出される項目に対して呼び出されるたびに、一部のファイルでデフォルトの$ CFLAGSなどを設定することはgcc非効率的です。関連メモリ量もごくわずかです。
• システム的な内容を含めることも、複数のアプリケーションを含めることもできます。共通点。

このリストにさらに追加することができますが、これでこの問題の長所と短所のアイデアを得ることができることを願っています。主な「メリット」と主な「デメリット」はグローバルネームスペースです。