/etc/profile.dのスクリプトは何をしますか？
基本的なシェルスクリプトについて Linuxコマンドラインとシェルスクリプト聖書 から読んでいます。
/etc/profileファイルは、Bash Shellの起動時に環境変数を設定すると言っています。 /etc/profile.dディレクトリには、アプリケーション固有の起動ファイルを含む他のスクリプトが含まれています。これらのスクリプトは、起動時にシェルによっても実行されます。
これらのファイルがBashの起動にも重要なのに、なぜ
/etc/profileの一部ではないのですか？これらのファイルがBashの起動に重要ではないアプリケーション固有の起動ファイルである場合、なぜそれらが起動プロセスの一部であるのですか？設定が含まれている特定のアプリケーションが実行された場合にのみ実行されないのはなぜですか？
これらのファイルがBashの起動にも重要なのに、なぜ/ etc/profileの一部ではないのですか？
「なぜそれらが1つの巨大なスクリプトに結合されていないのですか？」という意味の場合、答えは次のとおりです。
- それは、スクリプトを担当する人々にとって、メンテナンスの悪夢になるからです。
- スクリプトを独立したモジュールとしてロードすると、システム全体がより動的に調整可能になるため、他のスクリプトに影響を与えることなく、個々のスクリプトを追加および削除できます。等。
- これらは/ etc/profileを介してロードされるため、いずれにしても同じようにbashの「プロファイル」の一部になります。
これらのファイルがBashの起動に重要ではないアプリケーション固有の起動ファイルである場合、なぜそれらが起動プロセスの一部であるのですか？設定が含まれている特定のアプリケーションが実行されたときにのみ実行されないのはなぜですか？
それは、私が2つに分けられる、より広範な設計哲学の質問のように思えます。最初の質問は、シェル環境を使用することの価値と適切性についてです。プラスの価値はありますか？はい、便利です。それはすべての構成の問題に対する最良の解決策ですか？いいえ。ただし、単純なパラメータの管理には非常に効率的であり、広く認識され、理解されています。対照的に、そのようなものを異種混合で構成することを決定すると、おそらく$ PATHは別の独立したツールで管理でき、$ EDITORなどの優先ツールはsqliteファイルのどこかにあり、$ LC langはテキストファイルにある可能性があります。他の場所のカスタム形式など-env変数と/etc/profile.dを使用するだけでなく、突然簡単に見えますか？おそらく、env変数とは何か、それらがどのように機能し、どのように使用されるか、および適切に名前が付けられている「環境」の5つの異なるユビキタスな側面について5つの完全に異なるメカニズムを学習することはすでに知っています。
2番目の質問は、「これは適切なタイミングで起動しますか？」であり、あまり効率的ではない（使用される可能性のあるデータと使用されない可能性のあるすべてのデータなど）ことに異議を唱えます。だが：
- 実際には、それほど多くのデータではありませんが、一部の正しい考えでは誰もそれをいくつかの単純なパラメーターより多く使用しないためです（アプリケーションを構成する他の方法があるため）。
- よく使われるものに関して賢く使うと、たとえば、
gccを呼び出すたびにどこかからファイルのデフォルトの$ CFLAGSを設定するのは効率が悪くなります。関係するメモリの量は、やはり非常に小さいことを覚えておいてください。 - これには、複数のアプリケーションが関与する可能性のある体系的なものが含まれる可能性があり、シェルは共通基盤です。
さらにリストに追加することもできますが、うまくいけば、この問題の長所と短所についての考えが得られます。主要な「長所」と主要な「短所」は、グローバルな名前空間であることです。
これらのファイルはアプリケーションに固有ですが、アプリケーションの起動時ではなく、シェルの起動時に提供されます。構成ディレクトリは、他の多くの場所にあるのと同じ理由でここで使用されます。これにより、アプリケーションまたはソフトウェアパッケージで構成を変更できます。複数のパッケージが単一の構成ファイルを管理/更新しようとしていて、ユーザーによっても変更される可能性があるため、これは分割構成なしでは不可能です。
また、付記、/etc/profileは、bashだけでなく、すべてのシェルから提供されます。 bash固有の構成ファイルはbashrcであり、インタラクティブシェル用にのみ提供されます。
ヨルダンの答え は不正解です。 /etc/profileはすべてのシェルから供給されるわけではありません。ご指摘のとおり、csh、tcshがソースではありません-zshについてはわかりません。これは、Korn Shell（sh）やBASH（ksh）のようなBourne Shell（bash）の派生によって供給されています。 cshは/etc/loginを使用します。 Borne Shell誘導体のみを使用する傾向がある人々は、他のシェルが存在することを忘れがちです。彼らは「すべてのユーザー」に適用されることを期待して/etc/profileに何かを追加し、奇妙なCシェルユーザー（そして私たちが奇妙なロット）が/etc/profileで設定したものを持っていないことに驚いています。
それでも、他のBorne Shell派生シェルが存在することを忘れがちです。 bashまたはkshを使用している場合、変数を定義して同じ行にエクスポートするなど、Bourne Shellでは無効な/etc/profileに構文を自由に追加できます。次に、#!/bin/shを実行するいくつかのスクリプトを取得し、構文を窒息させます。 /etc/profileはBourne Shell互換の構文に固執する必要があります。
同様に、独自の.profileを使用する必要があります（bash構文が必要な場合は.bash_profileを使用します）。これは少し余分な入力となる場合がありますが、一度に行う追加の入力です。 ${HOME}などではなく~を参照します。一部の種類のUnix、cronジョブはshの下で実行され、Makefileの各行はshによって処理されるため、複数の種類のUNIXで作業している場合、.profileボーンシェルを維持することは本当に価値があります互換性があります。システム管理者として、.profileをBourne Shell互換になるように修正することで誰かを助けたことがあるかはわかりません。
Linuxでは、/bin/shは/bin/bashへのリンクであり、これを実行すると、実行に使用されたパスに見え、（理論的には）Bourne Shellがサポートするものだけに制限されます。同様に、Linuxのviは実際にはvimであり、再び制限されます。ときどき、「ブリードスルー」機能が表示されます。 vimの作成者が「vi後方互換性」モードでこれを無効にするのを忘れたため、viがvimがサポートしていることをviがサポートすることを、vimが行うことがあります。 bashがshのふりをして類似の「ブリードスルー」機能を備えていても、驚かないでしょう。一部の機能が「LinuxのBorne Shellで機能する」が、System VまたはBSDベースのUNIX（AIX、OpenBSDなど）では機能しない場合でも、驚かないでしょう。