環境変数という概念の重要性。生まれた経緯。

なぜ環境変数というものが生まれたのか。
設定ファイルとコマンドラインオプションの概念が有れば事足りるように思います。
(多分) ずっと昔に作られて、各種OSで使われているという事は、重要な概念だということを
意味していると推測します。しかし、その重要さが分かりません。
ファイルアクセスは昔はオーバヘッドが大きかったから使えなかったんでしょうか。
もしかして、環境変数が子プロセスに継承されるという性質が重要な役割を担ってるんでしょうか。
昔は価値があったが、今はあまり無い?
それとも、自分が使ってないだけで皆使っている?
特定の問題領域ではよく使われている?
とりとめの無い質問で申し訳有りませんが、よろしくお願いします。

No.1 回答者： dscripty 回答日時： 2012/04/28 15:49

設定ファイルを読み込む時も、環境変数がないとたいへんだよ？

$HOME/.application-name-rc

コマンドラインに毎回設定ファイル名を入力しなければならないなんて面倒……。

いったい、いくつの設定ファイルの名前を覚えれなくちゃならないんだろう？考えただけで憂うつになるよ？

歴史は、他の回答者の紹介する文書をみてね！

No.2 回答者： notnot 回答日時： 2012/04/28 20:25

多くの環境変数は、複数のプログラム（ほとんどの)が共通に使う設定を提供していますよね。

これをやめて、すべてのプログラム起動時に指定するのは面倒と言うよりあり得ない。

TEMPとか、HOMEとか、PATHとか、LANGとか、TERMとか。

あと、メモリ参照に比べての、ファイルアクセスのオーバーヘッドは昔も今も大きいですよ。

特定のプログラムだけで使うオプションを、設定ファイルで指定するのか環境変数で指定するのかというのは、確かにトレードオフがあるかと思います。使用頻度でしょうかね。例えば、ls のカラーオプションは、LS_COLORSという環境変数で設定されていますが、これを、$HOME/.lsrc /etc/lsrc のような設定ファイルから読むような仕様はありでしょう。ただ、ls 起動のたびに、追加で2ファイルをオープンするのはオーバーヘッドがあるのでトレードオフの検討で採用は否でしょうね。

この回答への補足

ご回答ありがとうございます。

> 多くの環境変数は、複数のプログラム（ほとんどの)が共通に使う設定を提供していますよね。
> これをやめて、すべてのプログラム起動時に指定するのは面倒と言うよりあり得ない。

こちらですが、例えば、~/Environmentsというファイル(名前は何でもいいですが)にPATH:..¥nTEMP:...¥n..というふうに書いておいて、どのプロセスもこれを参照すると決めることもできると思います。そうすれば、環境変数と同じ役割を果たせるのではないでしょうか。

また、このファイルを用意すれば、他のファイルと比べて使用頻度は格段に多くなるでしょうから、キャッシュへのアクセスで済むと思います。ディスクアクセスがなければ、環境変数へのアクセスとそれほど変わらないということにはなりませんか。

補足日時：2012/04/29 20:44

No.3 回答者： don_go 回答日時： 2012/04/29 07:24

例えば「PATH」環境変数はプログラムファイルの検索

対象を指定するものですが、これを設定ファイルから
取得しようとした場合、それがどのディレクトリ上に
有るかが判っていないといけません。
そうすると「PATH」の値を使って、実行プログラムの
有るディレクトリを探そうとしているのに、「PATH」
の値が取得できない事になります。
また、コンソール端末上で環境変数を変更した場合は
その値が反映されるのは、そのコンソール端末だけで
すが、設定ファイルの値を変更してしまうと、そうは
いかなくなります。

この回答へのお礼

ご回答ありがとうございます。

> また、コンソール端末上で環境変数を変更した場合は
その値が反映されるのは、そのコンソール端末だけで
すが、設定ファイルの値を変更してしまうと、そうは
いかなくなります。

これは知らなかったです。そうなんですね。

お礼日時：2012/04/29 20:49

No.4 ベストアンサー 回答者： notnot 回答日時： 2012/04/29 21:57

No2です。

＞こちらですが、例えば、~/Environmentsというファイル
LANGとかTERMは使う端末によって変わり得るわけですが、どうしますか？
あと、シェルコマンドラインからの実行時と、cron起動で環境を変えたいとかもありそう。

No3の方が書いてるように一時的に変えたいこともありますね。
例えば英文マニュアルが読みたいときは、bash等だと、
LANG=C man bash
これはmanにオプションを追加して man --lang=C bash のようにすればいいと思うでしょうが、manは内部で複数のプログラムを起動しているので、それら子プログラムにも全部その情報を伝えないといけない。

PATHをシェルスクリプトの中で設定し直すのはけっこうありますし、HOMEを一時的に変えて作業したいこともたまにはあります。

~/Environmentsを読むとしても、~ つまりHOMEの値を得るのも/etc/passwdを読む必要がありますね。HOME取得サブルーチンを標準ライブラリに追加するのでしょうけど、関数コール１つで得られるようになってもファイルを読むことには違いない。

他にファイルに書けない物として、動的に決まる環境変数もありますよね。ログイン接続元IPアドレスとか。シェルのネスティング階層とか。

先の回答に書いたように、ファイルオープンやリードのオーバーヘッドはそれなりにあるので、秒何百何千件もプロセスが生成されたりすると無視できない量になります。プロセス起動ごとに現在の物に追加して3つか4つあるいはそれ以上のファイルを読まないといけない。
単にメモリにアクセスするのと、ファイルを見に行ってたまたまキャッシュに載っているのを比べても全然違います。それにメモリはプロセス固有だけど、ファイルは共有資源なので排他制御が関係してくるとさらに遅い。例えば、ホームディレクトリを更新するプロセスがあるとその排他が解けるまで~/Environmentsが読めない。

この回答へのお礼

なるほど。まとめると、
* 呼び出す時の状況に応じて微妙に処理を変えたい事がある
* 環境変数だと、その変えたい処理を子プロセス・孫プロセスにも一緒に反映させることができる
* 秒間に100～1000プロセスくらいのプロセスが生成されることがあるため、ファイルオープンのオーバヘッドも馬鹿にならない
* ~/Environmentsなど1ファイルに情報をまとめていると、排他処理でボトルネックになる
ということですね。
理解できてきました。特にLANGを子プロセスに伝える所は納得しました。確かにコマンドラインオプションで伝えていくのは無駄ですね。
ありがとうございます!

お礼日時：2012/04/30 23:45