PATH HOWTO Esa Turtiainen etu@dna.fi v0.4, 15 November 1997 伊佐冶 哲, isaji@mxu.meshnet.or.jp Sun Mar 1 2:54:45 1998 このドキュメントはUnix/Linux環境変数、特にPATH変数の仕組みや問題点を 扱っています。 ______________________________________________________________________ 目次 1. イントロダクション 2. 著作権 3. 一般的なこと 4. Init 5. Login 6. シェル 6.1 bash 6.2 tcsh 7. ユーザーIDの変更 7.1 su 7.2 sudo 8. ネットワークサーバ 8.1 inetd 8.2 rsh 8.3 rlogin 8.4 telnet 8.5 ssh 9. XFree86 9.1 XDM 9.2 xterm -ls 9.3 ウィンドウマネージャメニューとボタン 10. cron、atコマンドについて 10.1 cron 10.2 at 11. いくつかの例 11.1 magicfilter 11.2 Xアプリケーションからの印刷 12. セキュリティの考察 13. 問題のデバッグの仕方は？ 14. 全ユーザーが同じパスを得るための方法 15. 謝辞 ______________________________________________________________________ 1. イントロダクション このドキュメントはUnix/Linux環境変数、特にPATH変数の仕組みや問題点を 扱っています。PATHはコマンドを探すディレクトリのリストです。 Debian Linux 1.3配布パッケージを対象としています。 注意！このドキュメントはβリリースです。コメントや訂正などありましたら 連絡して下さい。 2. 著作権 This documentation is free documentation; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This documentation is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this documentation; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. このドキュメントはフリー文書です。Free Software Foundationによる GNU General Public License(バージョン2かそれ以降)の条件の元で修正、再配付 することができます。 このドキュメントはユーザーの役に立つことを願って配付されていますが無保 証です。特定の目的に関する商業的あるいは適合性の保証もありません。詳し くはGNU General Public Licenseを参照して下さい。 このドキュメントが従っているGNU General Public Licenseのコピーを手にい れておいて下さい。もしなければ Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA に連絡して下さい。 3. 一般的なこと 全てのUnixプロセスは"環境(environment)"を含んでいます。これは名前と値 をから成る変数のリストで、これらの文字に多くのキャラクタを入れることが できます。全てのUnixプロセスは親プロセスを持っています -- 親プロセスが 作るプロセスは子プロセスです。子プロセスは親プロセスから環境を引き継ぎ ます。子プロセスに順番に環境を渡す前に、その環境に修正を加えることがで きます。 重要な環境変数のひとつはPATHです。これはコロン(:)によって分けられた ディレクトリのリストです。これらのディレクトリはfindコマンドで検索され るものでもあります。例えばコマンドfooを実行しようとすると、PATH にある ディレクトリ全てを実行ファイルfooの検索対象としますファイルが見つかる とそこで実行されます。 このHOWTOでは「コマンド」を実行プログラムを指すものとして使います。パ ス機能を使って短い名前(short names)で呼び出されることを意味していま す。 Linuxでは、プロセス(呼び出しのexec関連)を開始するための低水準なオペレ ーティングシステムコールでさえもPATH変数にあるディレクトリを検索しま す。コマンドを実行しようとする時はいつでもパス機能を使うことができま す。もしexecオペレーティングシステムコールが/(スラッシュ)を含まない ファイル名を得ようとするさいにはPATH環境変数を評価します。環境にPATH変 数がない時でさえ、少なくとも/binと/usr/bin ディレクトリでコマンドを探 します。 shではexportコマンドを環境の設定に使います。またcshではsetenvが使われ ます。例えば： sh: PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:. csh: setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:. Cプログラムはsetenv()ライブラリコールを環境の変更に使います。Perlは配 列 %ENVに環境を持っていて、PATH を$ENV{PATH}="/bin"としてセットできま す。 envコマンドは現在の環境変数を調べる基本的な方法です。同様に環境変数の 修正にも使うことができます。 基本的な環境メカニズムの情報については、 manページのenviron, execl, setenv、infoファイルenv そしてシェルのドキュメントに書かれています。 Linuxが起動すると、はじめに開始する通常プロセスはinitプロセスです。こ れは親プロセスを持っていない点で特殊なプロセスであるということができま す。そしてinitプロセスは他の全てのプロセスの先祖(ancestor：大もと)で す。 init環境は、実質的にinitに触れなくても、全プロセスの環境として残 されます。ほとんどのプロセスはタッチします。 initはプロセスのグループを開始します。/etc/inittabファイルはどのプロセ スをシステムスタートするか指定します。これらのプロセスは initから直接 継承される環境で動作します -- 典型的にはgettyといったプロセスです(コン ソールにlogin:を表示するプログラム)。もしここでPPP接続を開始するとき は、init環境で動作していることを忘れてはなりません。システム初期化はこ こで開始されるスクリプトです。Debian 1.3の初期化スクリプトは /etc/init.d/rcで、順番に初期化スクリプトが呼び出されます。 システムは多くのサーバ(デーモン)を走らせています。これらはデフォルトの 環境で使うものもあればそうでないものもあります。ほとんどのサーバは初期 化スクリプトからこれらを開始し、そのためinit環境であると考えることがで きます。 ユーザーがシステムにログインすると、環境はプログラム/システム広範の初 期化スクリプト/ユーザー初期化スクリプトに組み込まれる設定によって反映 されます。これはよい組み込まれかたですが現在の状態が完全に満足のいくも のではありません。ユーザーがテキストコンソールからログインする時 とXDM、ネットワークからログインする時とではまったく違うものとなりま す。 4. Init Initは他のシステムプロセス全ての親プロセスです。他のプロセスは initプ ロセスの環境を継承して、パスはinitパスです(稀なケースではその他のパス がセットされていない)。 「init path」はinitプログラムのソースに用意されています： /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin initパスには/usr/local/binは含まれていないことに注目して下さい。 /etc/inittabから開始するプログラムは全てinit環境、特に /etc/init.d(Debian 1.3)のシステム初期化スクリプトで動作します。 システム初期化スクリプトから開始するものは全てデフォルト環境として init環境を持っています。例えばsyslogd, kerneld, pppd(startupから始まっ た時)、 gpm、そして重要なlpd、inetdはinit環境を持っていて、その環境を 変更することはしません。 プログラムのグループはstartupスクリプトから開始されPATH環境変数は startupスクリプトに明示的にセットされています。例：atd, sendmail, apache、squid。 ブートスクリプトから開始するけれどパスを完全に変更する他のプログラムが あります。そのような例はcronです。 5. Login テキストコンソールにはユーザーログインを待つgettyプログラムがありま す。 "login:"とメッセージを表示します。init環境で動作し、gettyがユーザ ーをシステムにログインさせたら「login」プログラムを実行します。こ のloginプログラムはユーザー環境をセットしシェルを実行します。 ログインプログラムは/usr/include/paths.hにパスを定義しています。この 「ログインパス」はrootユーザーと他のユーザーでは違いがあります。 一般ユーザー用(_PATH_DEFPATH)： /usr/local/bin:/usr/bin:/bin:. root用(_PATH_DEFPATH_ROOT)： /sbin:/bin:/usr/sbin:/usr/bin 一般ユーザーのパスはsbinディレクトリを含んでいません。しかしカレント ディレクトリ(.)を含んでいます。カレントディレクトリはrootユーザーでは 危険です。rootユーザーにおいては/usr/local/binにもパスを通していませ ん。 ログインパスはシェル初期化によって上書きされることがあります。しかしユ ーザーシェルとして/etc/passwdに他のプログラムを指定することも可能で す。例えば特殊ユーザー名でログインした時PPPを開始する以下のような行を 使っています。このケースではpppdがログインパスとして正しく書かれていま す。 etu-ppp:viYabVlxPwzDl:1000:1000:Esa Turtiainen, PPP:/:/usr/sbin/pppd 6. シェル ユーザープロセスは/etc/passwdで書かれているシェルの子プロセスです。 シェルの初期ファイルはパスを修正することがあります。 ログインではシェルの名前は-を前置きします。例えばbashは-bashのようにし て呼ばれます。これはシェル(つまりloginシェル)にシグナルを送ります。こ の場合、シェルはlogin初期化ファイルを実行します。そうでなければある 初期化が実行されます。 加えてシェルはそれがインタラクティブかどうかチェックします - ファイル やインタラクティブなttyからのコマンドです。これはシェルの初期化を修正 して、その結果インタラクティブではない(non-interactive)non-loginシェル が初期化されます。bashはここではなんの初期化ファイルも実行しません。 6.1. bash 通常のloginシェルとして、bashはシステム広範(system-wide)のファイル /etc/profileを使い(sources)ます。このファイルはシステム環境とパス をbashユーザー用にセットします。しかしシステムがnon-interactiveとして 実施された時はこれは実行されません。もっとも重要なケースは、隣りのマシ ンで実行されるリモートコマンドがrshで行われた場合です。/etc/profileは 実行されずパスはrshデーモンから継承されています。 bashはコマンドライン引数-loginと-iを受け取ります。この引数はそれぞ れloginシェルあるはインタラクティブ(interactive)シェルとしてシェルを セットするのに使われます。 ユーザーは~/.bash_profile, ~/.bash_login、~/.profile ファイルを作るこ とで/etc/profileでセットされている値を上書きすることができます(つまり ユーザーの設定)。これらのファイルのひとつめ(~/.bash_profile)はcsh初期 化のロジックと違うことに注意して下さい。~/.bash_loginは loginシェルに 関しては特に何も実行せず、また.bash_profileがあるときは全く実行されま せん！ もしbashが"bash"という名前の代わりにshとう名前として使用されていると、 オリジナルのBourne shell初期化をエミュレートします：その際のファイル は/etc/profile、~/.profileそしてloginシェル用のものです。 6.2. tcsh loginシェルとしてtcshは以下のファイルをこの順に実行します： o /etc/csh.cshrc o /etc/csh.login o ~/.tcshrc o ~/.cshrc(もし.tcshrcが見つからない時) o ~/.history o ~/.login o ~/.cshdirs tcshはcshrcスクリプトの前にloginスクリプトを実行するように組み込めるこ とにも注意して下さい！ インタラクティブでないシェルは*cshrcスクリプトを実行します。*login ス クリプトはloginで一回だけパスをセットするのに使われます。 7. ユーザーIDの変更 7.1. su suコマンドは新しいユーザーIDを使うためのものです。ユーザーIDを指定しな いと rootが使われます。 普通、suは違うユーザーIDでサブシェルを実行します。引数-(最近のシノニム は-lあるいは--login)で、ログインシェルのようにシェルを実行します。しか しログインプログラムを使いません 通常のユーザー： /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:. rootユーザー： /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin suは多くの細かい環境も変更します。 7.2. sudo スーパーユーザーコマンドを安全に使うためのコマンドのグループがありま す。よいログイン、ユーザーベースの制限、個々のパスワードの使い方を可能 にします。もっともよく使われているのはsudoです。 $ sudo env はスーパーユーザーとしてコマンドenvを実行します(使えるように設定されて いる時)。 sudoコマンドはパス操作の異なるアプローチをもっています。sudoは検索パス を修正してカレントディレクトリは最後になります。しかしPATH環境変数は変 更しません。sudo envやenvはPATH変数と同じ値を返します。 sudoはSUDO_USERといった２つの環境変数を追加します。 8. ネットワークサーバ ほとんどのネットワークサーバはある種のサブプロセスを実行しません。セ キュリティ的な理由からそれらのパスは最小限に押さえられています。 重要な例外はネットワークからシステムにログインできるようにするサービス についてです。この章では、このケースにおける環境とは何かについて解説し ていきます。rshを使ってリモートマシンでコマンドが実行されると sshで実 行されるものとは違うパスになっていることなどを見ていきましょう。同様 にrlogin、telnet、sshでのログインの違いなども見ていきます。 8.1. inetd ほとんどのネットワークサーバーは"常時リクエストを待っているプロセス "を持っていません。この動作はinetdと呼ばれるInternet super serverに一 括して委任(delegated)されています。inetdは定義されたネットワークポート を全て監視し、リクエストがあったときに適当なサーバーを開始します。この 振る舞いは/etc/inetd.confで定義されています。 inetdはシステム開始時のスクリプトから起動されていて、initプロセスのパ スを継承しています。このパスを修正する必要はありません。またinetdから 開始する全てのサーバはinitパスを使います。そのようなサーバの例はimapd やIMAP post office protocolのサーバといったものです。 inetdプロセスのその他の例はtelnetd, rlogind, talkd, ftp, popd そし てhttpサーバなどです。 実際のサーバーを開始するために別々にtcpdプログラムを使う場合、inetdの 使い方は複雑です。tcpdは実際のアプリケーションを開始する前にそのセキュ リティをチェックするというプログラムで、パスに影響は与えません(確認し ていません)。 8.2. rsh rshデーモンは_PATH_DEFPATH(/usr/include/paths.h)からのパスをセットしま す。これは通常ユーザーとしてloginプログラムが使うのと同じパスです。 rootは通常ユーザーと同じパスを得ます。 実際にはrshdはコマンドラインで shell -c command-line とします。またシェルはログインシェルではありません。/etc/passwdに書か れている全てのシェルはコマンドラインで与えられる-cオプションをサポート しているほうが望ましいです。 8.3. rlogin rloginは実際のログイン処理を行うためにloginを実行します。rloginを使っ てログインするとloginと同じパスを得ます。Linuxコンピュータにログインす るためのその他の方法ではloginを使いません。rshとの違いに注意して下さ い。 実際に使うloginコマンドは login -p -h host-name user-name です。-pオプションはHOME, PATH, SHELL, TERM, MAIL, LOGNAME といった環 境変数以外の環境を保存するオプションです。 -hはログインするリモートホ ストの名前を指定するオプションです。 8.4. telnet telnetはrloginに似ています。telnetはloginプログラムを使っていてコマン ドラインも同じような方法で実行されます。 8.5. ssh sshはそれ自身のパス設定を持っています。sshがあるディレクトリを追加した ディレクトリです。これは/usr/binがパスに2度出てくるということを意味し ています： /usr/local/bin:/usr/bin:/bin:.:/usr/bin パスには/usr/X11/binディレクトリはありません。またsshコマンドによって 実行されるシェルはloginシェルではありません。こうして ssh remotehost xterm では全く動作しません。/etc/profileあるいは/etc/csh.cshrc に書かれてい ることはこれを変更できてしまいます。そこで絶対パス /usr/bin/X11/xtermと入力しなければなりません。 sshは/etc/environmentファイルかたVAR=VALUEフォームの環境変数を検索しま す。残念なことにこれはXFree86で問題を生じます。 9. XFree86 9.1. XDM XDMはグラフィカルターミナルにログインするのによく使われる方法です。一 見するとloginのように感じられますが内部的には全く異なるものです。 /etc/X11/xdmディレクトリには、ログインそれぞれで実行される設定ファイル があります。Xstartup("Xstartup_0" はスクリーン0用)はユーザーがログイン した後で実行されるコマンドが書かれています(コマンドはrootとして実行さ れます)。 ユーザー用にセットされたパスは/etc/X11/xdm/xdm-configにあります。そこ には DisplayManager*userPath: /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games DisplayManager*systemPath: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 といった行があります。これらはそれぞれ通常ユーザーとrootのデフォルトパ スです。Xユーザーなら /usr/bin/X11にパスが通っていることはとても重要で す。もしXユーザーが他のマシンにログインしてXクライアントアプリケーショ ンを起動する場合、 /usr/bin/X11はXターミナルから直接参照されないパスな ので /usr/bin/X11を入力しなくてはいけません。 Xstartupを走らせて、XDMは最終的なユーザー(final user)として /etc/X11/Xsessionを走らせます。ローカル設定は /etc/environmentにあり、 もしこれがあればXsessionで使われます。 (Xsessionは/bin/shから実行され ます。つまり/etc/environment はshファイルである必要があります)。これ はsshとクラッシュします。 sshは、/etc/environmentはVAR=VALUEフォームの 行を含んでいるファイルとするからです。 9.2. xterm -ls デフォルトではX windowマネージャーのメニューから起動される全てのコマン ドのパスはXDMから継承されています。違うものを使うなら正しくセットする 必要があります。"通常の"パスを使ってターミナルエミュレータを起動するに は、特殊オプションを使います。xtermでは、シェルログイン初期化ファイル で指定されたパスでログインシェルを使うのに、-lsオプション(loginシェ ル)を使わなければいけません。 訳注：xterm manページの-lsオプションの箇所を参照して下さい。 9.3. ウィンドウマネージャメニューとボタン ウィンドウマネージャはXDMの環境を継承しています。ウィンドウマネージャ によって起動されるプログラムは全てウィンドウマネージャの環境を継承しま す。 ユーザーシェル環境はウィンドウマネージャのボタンやメニューから起動する プログラムに影響しません。例えばxterm -lsから実行したプログラムはログ インシェルの環境を使い、メニューから起動したプログラムはウィンドウマネ ージャの環境を使います。 10. cron、atコマンドについて 10.1. cron cronは/etc/crontabやユーザーが定義したcrontabで指定されたコマンドを定 期的に実行するためのコマンドです。Debian 1.3では /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthlyを使います。 cronはブートスクリプトから開始しますが、cronのパスがおかしいようです： /usr/bin:/binn:/sbin:/bin:/usr/sbin:/usr/bin これはcronのバグです。これはterminating 0なし(without terminating 0) ではじめに上書きされた/usr/bin:/binがあるinitパスです！このバグは全て のシステムにあるわけではありません。 crontabでPATH定義をすることができます。Debian 1.3を使っているなら /etc/crontabのはじめに以下の行があります： PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin このため、crondプログラムのパスはユーザープログラムで使われることは決 してありません。/etc/cron.*ディレクトリの全スクリプトはデフォルトでこ のパスを参照します。プログラムがroot以外で実行された時でもこのパスが使 用されます。 10.2. at atは特定の時間に一度だけプログラムを実行するのに使われます。 atdはinitパスを使います。しかしユーザープログラムは常にshコマンドを 使ったユーザー環境で実行されます。そこで通常のシェル上書き(usual shell overwrites) が行われます。``bash''の章を参照して下さい。 11. いくつかの例 11.1. magicfilter magicfilter印刷ファイルを操作するためのツールです。印刷するためのファ イルタイプを解析して、適当なちょっとよい印刷 (pretty-printing)を行うた めのフィルタスクリプトを実行します。これらのスクリプト はlpd(/etc/init.d/lpd)から実行されます。 lpdはinitから開始します。つま りmagicfilterのパスはinitのもので、 /usr/bin/X11にはパスは通っていませ ん！ magicfilterにPDFファイルの印刷を入れたいという場合は、 /usr/bin/X11/xpdfを使ってこれを行うことができます。magicfilterは initから継承されたパス以外のプログラムは見つけられないので、ファイル名 をフルパスで書く必要があります。magicfilterで使われるほとんどのプログ ラムは、 /bin、/usr/binにあるので、フルパス必要としません。 訳注：「The Linux Printing HOWTO」佐藤亮 一(GFG02131@niftyserve.or.jp)さん訳の "6. 適切なマジックフィルターの 入手法"を参照して下さい。 JFサイト から入手できます。 11.2. Xアプリケーションからの印刷 PRINTER環境変数はどのプリンタを使っているかを示すのに使われます。しか しXアプリケーションではこれが使われないことがあることに注意して下さ い。 XセッションがXDMから始まった場合は、ウィンドウマネージャはシェルlogin スクリプトを全く評価しません。xtermからスタートしたXアプリケーション はPRINTER変数を引き継いでいます。しかし、もしメニューやウィンドウマネ ージャのボタンから同じアプリケーションを起動してもPRINTER変数は引き継 ぎません。 ある場合、これは下位のレイヤ(lower layer)に継承することができます。例 えばNetscape補助アプリケーションはPRINTER定義を引き継ぐことも引き継が ないこともできます。 12. セキュリティの考察 パスには重要なセキュリティ問題があります。パス設定の間違いを悪用して、 システムにクラック(原文：hack)するのによく使われる方法です。もしクラッ カー (原文：hacker)がroot、一般ユーザーでクラッカーのコマンドを実行す ると、簡単に「トロイの木馬(Trojan horse)」攻撃がなされてしまいます。 昔(?)のよくあったミスはrootのパスに.(カレントパス)を入れるといったもの です。悪意のあるハッカー(クラッカー)は彼のホームディレクトリでプログラ ムlsを作り、もしrootが # cd ~hacker # ls と実行するとクラッカーのlsコマンドを実行してしまいます。 間接的にこれはrootとして実行されるプログラム全てに適用されます。重要な デーモンプロセスでは他のユーザーが書き込めないようにするべきです。ある システムでは/usr/local/binにセキュリティ的に不十分なプログラムでも置く ことができます - そのためrootユーザーのパスから /usr/local/binを除外し ておくべきです。しかしもしあるデーモンがパス/usr/local/bin/:...を使っ たfooを実行していると、 /bin/fooではなく/usr/local/bin/fooを実行するこ とも可能です。そして/usr/local/binに書き込めるユーザーはだれでもシステ ムを壊すことができてしまいます。 パスのディレクトリの順番に注意を払うのも大変重要です。例えば、 /usr/local/binが/binの前にあるとセキュリティリスクが生じます - も し/binの後に/usr/local/binがあれば、 /bin/fooコマンド を/usr/local/bin/fooとローカルに修正したもので上書きすることはできませ ん(つまりこの方がセキュリティ的に安全です)。 Linuxでは、パスの評価がオペレーティングシステムコールレベル(operating system call level)で行われていることを思い出して下さい。実行ファイルの パスが与えられているところならどこでも、(少なくとも) /bin、/usr/binか ら検索される短い名前(short name)が与えられます - 他の場所でも同様で す。 13. 問題のデバッグの仕方は？ 環境を表示(read)するための基本的なコマンドは/usr/bin/envです。 あるプログラムのパスを見つけるのに/procディレクトリを使うことも可能で す。はじめにプログラムのプロセス番号を調べて下さい - psコマンドを使い ます。例えばxtermのプロセス番号が1088なら、 # more /proc/1088/environ としてxtermの環境を表示することができます。これはxdmといったデーモンプ ロセスでは動作しません。システムプロセス、他のユーザープロセスの環境に アクセスするにはrootアクセスが必要です。 Netscapeをデバッグするために、/tmp/testスクリプトを作ることもできま す： $ cat > /tmp/test #!/bin/sh /usr/bin/env > /tmp/env ^d $ chmod +x /tmp/test そして適当な補助アプリケーションをセットします(例えばaudio/x-pn- realaudioに RealAudio)。(http://www.realaudio.com/showcaseの)RealAudioリンクを閲覧 してみて下さい。Netscapeは/tmp/envにストアされている環境のダミープログ ラムを呼び出します。 14. 全ユーザーが同じパスを得るための方法 もっとも重要な設定は、loginシェル用のグローバルシェル初期化ファイルに セットすることも可能です：/etc/csh.login(tcsh)、 /etc/profile(bash)。 これらのファイルから正確なパスを得ないといった例外として： rshコマン ド、sshコマンド、(loginシェルをはっきりと開始しない)X window manager のメニューアイテム、inittabから実行されるコマンド、cronジョブ、lprdか ら起動されるmagicフィルタのようなデーモンジョブ(daemons jobs)、WWW CGIスクリプトなどがあります。 もし/etc/csh.cshrcにパスがセットされていると、 tcsh/cshを使ったアカウ ントのリモートマシンでrsh、sshからコマンドを実行した時でも、正しいパス が通っています。 1つのファイル(例えば/etc/environment-common)にパス設定をまとめることも 可能です。例えば、 ${EXPORT}PATH${EQ}/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/usr/local/bin:/usr/games:. とします。これは/etc/csh.login(tcsh、csh)から使われます： set EQ=" " set EXPORT="setenv " source /etc/environment-common また/etc/profile(bash、オリジナルshとして動作しない)： EQ='=' EXPORT="export " . /etc/environment-common /etc/environment(XDM用)： EQ="=" EXPORT="export " . /etc/environment-common この方法はだいたい動作しますが、sshは/etc/environment(環境変数EQ、 EXPORT定義)の行で不平を言うかもしれません。またbashで実行するrshコマン ドはこのパスを継承しないかもしれません。 15. 謝辞 このドキュメントを書き始めた理由のひとつはAri Mujunen氏(amn@bigbang.nfra.nl) の大きな不満があったということです。 Juha Takala氏には価値あるコメントをいただきました。