/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非効率的です。関連メモリ量もごくわずかです。
• システム的な内容を含めることも、複数のアプリケーションを含めることもできます。共通点。

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

これらのファイルはアプリケーションごとに異なりますが、アプリケーションの起動時ではなく、シェルの起動時に生成されます。構成ディレクトリは、他の多くの場所で見つけることができるのと同じ理由でここで使用されます。これにより、アプリケーションまたはソフトウェアパッケージが構成を変更できます。分割構成がないと、ユーザーが変更できる単一の構成ファイルの複数のパッケージを管理/更新しようとすると、エラーが発生しやすく混乱するため、これは不可能です。

また、/etc/profileこれはbashだけでなく、すべてのシェルで提供されることに注意してください。 Bash 関連の構成ファイルは bashrc であり、対話型シェルでのみ使用できます。

ジョーダンの答え不正確です。/etc/profileすべての殻がここに由来するわけではありません。指摘した通りで作ったものではありませんcsh。tcsh- よくわかりませんzsh。 Korn Shell（）、BASH（）shなどのBourne Shell（）派生から派生しました。 Borne Shell派生製品のみを使用している人は、他のシェルが存在することを忘れる傾向があります。彼らは「すべてのユーザー」に機能すると期待するものを追加し、奇妙なCシェルユーザー（私たちは奇妙な人です）が 。kshbashcsh/etc/login/etc/profile/etc/profile

それにもかかわらず、人々は他のBorne Shellデリバティブが存在するという事実を忘れる傾向があります。bashまたはを使用すると、変数を定義して同じ行にエクスポートするなど、Bourne Shellで無効な構文をksh自由に追加できます。/etc/profileその後、実行可能なスクリプトを取得しまし#!/bin/shたが、その構文はめちゃくちゃです。/etc/profileBourne Shell互換の構文に従う必要があります。

繰り返しますが、直接使用する必要があると主張する必要があります.profile（.bash_profilebash構文が必要な場合は使用してください）。追加の入力が必要な場合がありますが、一度に追加の入力が必要です。参照${HOME}であり、同じではありません~。特定のUnixバージョンでは、cronジョブはsh各行の下で実行されるため、さまざまなUNIXバージョンで作業している場合は、Bourneシェルの互換性を維持することが実際に役立ちます。システム管理者として、私は他の人がBourne Shell互換性の問題を解決するのに何度も助けたかもしれません。Makefilesh.profile.profile

Linuxでは、実行時に実行に使用されたパスを見つけ、（理論的には）Bourne Shellがサポートするパスに限定されている/bin/shリンクです。/bin/bash繰り返しますが、viLinuxではvim自分自身を制限します。時々、機能が「流れる」ことがわかります。時にはサポートされているアクションを実行するふりをしていますvimが、作成者が「vi下位互換性」モードで無効にすることを忘れたため、サポートされていません。 Pretendに同様の「浸透」機能があるとしても、私は驚かないでしょう。一部の機能は「LinuxのBorne Shellで動作します」が、System VまたはBSDベースのUNIX（AIX、OpenBSDなど）では動作しなくても驚かないでください。vivimvivimbashsh