開いているすべてのターミナルで「source .profile」を使用する必要があるのはなぜですか？

~/.profileUbuntuで変数を変更するときは、コマンドを実行しsource .profileます。その後、変更はこの端末でのみ有効です。新しいターミナルを開く場合は、コマンドをsource .profile再度実行する必要があります。そのため、同じユーザーに属していても、異なる端末には独自の環境があるようです。

すべての端末に独自の環境パスを持たせる利点は何ですか？同じユーザーに属している異なる端末が同じ環境変数を共有している方が良いようです。

この理由は、~/.profileログインシェルによってのみ供給されるためです。新しいターミナルウィンドウを開くと、起動するシェルはデフォルトで非ログインシェルです。ログアウトしてから再度ログインすると、への変更~/.profileはすべての端末で有効になります。これ~/.profileは、セッションへのログイン時にソースが提供されるためです。

端末ウィンドウごとに異なる環境があるわけではありませんが、ソーシングは現在のシェルで~/.profileのみ実行さ~/.profileれます（それがまさにsourceコマンドの機能です）。

対照的に、への変更は、~/.bashrc開いているすべての新しいターミナルウィンドウ、またはと入力して開始したすべてのBashシェルにすぐに影響しますbash。

環境変数はユーザーの好みだけのものではありません。これらは、親プロセスから開始される子プロセスにさまざまな設定情報を伝達するための一般的なメカニズムです。

プロセスが開始するプロセスのみに影響を与えるために、プロセスが特定の環境変数を設定するケースは多数あります。たとえば、スクリプトは開始したコマンドのロケール設定を意図的にリセットし、それらからの出力を解析できるようにします。多くの大規模なソフトウェアパッケージのビルドスクリプトはmake、環境変数を介して相互に調整するネストされた呼び出しを使用します。特殊なツールは、$ LD_PRELOADまたは$ PATHでトリックを実行することによって開始する他のプログラムの動作条件を変更する必要がある場合があります。

長いコンパイルが別のウィンドウで実行されているときにユーザーが別のウィンドウで何かを行うと、背後にあるすべてのプロセスの環境変数が魔法のように変化するだけで、狂気と混乱が生じます。

他の環境変数には、プロセスが開始された特定のセッションに関する情報が含まれています。プログラムは、$ TERMが接続されている特定の端末（または端末エミュレータ）のコマンドセットを記述することを期待します。ユーザーごとの一般的な設定を行うと、いくつかの異なる種類の端末を使用して同じシステムにログインできなくなります。端末ハードウェアが1つしかなく、リモートでログインしない場合でも、そのようなプログラムはscreen、セッション内で実行されるプロセスに別の$ TERMを設定することに依存しています。

より良い質問は、ユーザーごとのデータベースではなく、なぜユーザー設定のプロセスにサブプロセス間の通信メカニズムを使用するのでしょうか。

回答：それは十分に機能し、ユーザーごとのデータベースを作成する利点は、環境変数の代わりにそれを使用するようにすべてを変更する作業が行われるほど大きくないためです。

（たとえば、単一のスクリプトを実行するためだけに変更するのが便利なユースケースがないような設定は非常に少ないと考えることができます。そのため、機能を失わないようにするために、すべてを次のようにオーバーライドする必要があります。環境変数。これにより、複雑さが増し、ユーザーが混乱します）。

代替案が存在しないかのようではありません。たとえば、Xリソースはプロセスごとではなく、ディスプレイセッションごとです。通常はさえないリモートログインのための作業に必要なコマンドラインプログラム-しかし、彼らは、コマンドラインプログラムのアクセスが困難である持っているに接続するXサーバを。