PATH HOWTO <author>Esa Turtiainen <tt/etu@dna.fi/ <date>v0.4, 15 November 1997 <trans>伊佐冶 哲, <tt/isaji@mxu.meshnet.or.jp/ <tdate>Sun Mar 1 2:54:45 1998 <abstract> このドキュメントはUnix/Linux環境変数、特にPATH変数の仕組みや問題点 を扱っています。 </abstract> <!-- Table of Contents --> <toc> <sect>イントロダクション <!-- Introduction --> <p> <!-- This document describes common tricks and problems with Unix / Linux environment variables, especially with PATH variable. PATH is a list of directories where commands are looked for. The details apply for Debian Linux 1.3 distribution. --> このドキュメントはUnix/Linux環境変数、特にPATH変数の仕組みや問題点 を扱っています。PATHはコマンドを探すディレクトリのリストです。 Debian Linux 1.3配布パッケージを対象としています。 <p> <!-- Note! This document is in beta release status. Please send comments and corrections. --> 注意！このドキュメントはβリリースです。コメントや訂正などありましたら 連絡して下さい。 <sect>著作権 <!-- Copyright --> <p> 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. <p> 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. <p> 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. <newline> 訳：(原文が優先されます)<p> このドキュメントはフリー文書です。Free Software Foundationによる GNU General Public License(バージョン2かそれ以降)の条件の元で修正、再配付する ことができます。 <p> このドキュメントはユーザーの役に立つことを願って配付されていますが 無保証です。特定の目的に関する商業的あるいは適合性の保証もありません。 詳しくはGNU General Public Licenseを参照して下さい。 <p> このドキュメントが従っているGNU General Public Licenseのコピーを 手にいれておいて下さい。もしなければ <tt>Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA</tt> に連絡して下さい。 <sect>一般的なこと <!-- General --> <p> <!-- All the Unix processes contain an "environment". This is a list of variables that contain name and value, both just strings that can contain most characters. All Unix processes have a parent process - the process that created this process as child. Child processes inherit environment from parent process. They can make some modifications to the environment before passing it in turn to their child processes. --> 全てのUnixプロセスは"環境(environment)"を含んでいます。これは名前と値を から成る変数のリストで、これらの文字に多くのキャラクタを入れることが できます。全てのUnixプロセスは親プロセスを持っています -- 親プロセスが 作るプロセスは子プロセスです。子プロセスは親プロセスから環境を引き継ぎま す。子プロセスに順番に環境を渡す前に、その環境に修正を加えることができます。 <p> <!-- One important environment variable is PATH, a list of directories separated by colons (':'). These directories are searched through to find commands. If you try to invoke command 'foo', all the directories in PATH (in that order) are searched for an executable file 'foo' (one with x-bit on). If a file is found, it is executed. --> 重要な環境変数のひとつはPATHです。これはコロン(<bf/:/)によって分けられた ディレクトリのリストです。これらのディレクトリはfindコマンドで検索 されるものでもあります。例えばコマンドfooを実行しようとすると、PATH にあるディレクトリ全てを実行ファイルfooの検索対象とします ファイルが見つかるとそこで実行されます。 <p> <!-- In this howto, I use term 'command' to refer executable program that is meant to be called with short names, using the path mechanism. --> このHOWTOでは「コマンド」を実行プログラムを指すものとして使います。 パス機能を使って短い名前(short names)で呼び出されることを意味しています。 <p> <!-- In Linux, even the low level operating system calls to start processes (the exec family of calls) searches through directories in the PATH variable: you can use the path mechanism anywhere where you try to execute a command. If exec operating system call gets a file name that does not contain '/', it evaluates the PATH environment variable. Even if there is no variable PATH in the environment, at least directories /bin and /usr/bin are looked for suitable commands. --> Linuxでは、プロセス(呼び出しのexec関連)を開始するための低水準なオペレー ティングシステムコールでさえもPATH変数にあるディレクトリを検索します。 コマンドを実行しようとする時はいつでもパス機能を使うことができます。 もしexecオペレーティングシステムコールが<bf>/</bf>(スラッシュ)を含まない ファイル名を得ようとするさいにはPATH環境変数を評価します。 環境にPATH変数がない時でさえ、少なくとも<tt>/bin</tt>と<tt>/usr/bin</tt> ディレクトリでコマンドを探します。 <p> <!-- In sh you use export command to set environment, in csh you use setenv command. For example: --> shでは<bf/export/コマンドを環境の設定に使います。 またcshでは<bf/setenv/が使われます。例えば： <p> sh: <tscreen><verb> PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:. </verb></tscreen> <p> csh: <tscreen><verb> setenv PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:. </verb></tscreen> <p> <!-- C-programs can use setenv() library call to change environment. Perl has environment in an associative array %ENV, you can set PATH as $ENV{PATH}="/bin". --> Cプログラムは<tt/setenv()/ライブラリコールを環境の変更に使います。Perlは 配列 <tt>%ENV</tt>に環境を持っていて、PATH を<tt>$ENV{PATH}="/bin"</tt>としてセットできます。 <p> <!-- env command is the basic way of asking the current environment variables. It can be used to modify it as well. --> envコマンドは現在の環境変数を調べる基本的な方法です。同様に環境変数の 修正にも使うことができます。 <p> <!-- More information of the basic environment mechanism can be found from manual pages 'environ', 'execl', 'setenv', info file 'env' and documentation of shells. --> 基本的な環境メカニズムの情報については、 manページの<bf/environ/, <bf/execl/, <bf/setenv/、infoファイル<bf/env/ そしてシェルのドキュメントに書かれています。 <p> <!-- When Linux boots up, the first normal process that starts is the init process. It is a special process because it does not have parent. However, it is the ancestor of all the other processes. Init environment will remain as environment of all the processes if they do not touch it explicitly. Most processes do touch. --> Linuxが起動すると、はじめに開始する通常プロセスはinitプロセスです。 これは親プロセスを持っていない点で特殊なプロセスであるということができます。 そしてinitプロセスは他の全てのプロセスの先祖(ancestor：大もと)です。 init環境は、実質的にinitに触れなくても、全プロセスの環境として残されます。 ほとんどのプロセスはタッチします。 <p> <!-- Init starts a group of processes. File /etc/inittab tells what processes the system starts. These processes work in the environment that is directly inherited from init - typically they are processes like 'getty', the program that writes 'login:' to console. If you start PPP connections here, you must remember that you are working in the init environment. The system initialization is often a script that is started here. In Debian 1.3 initialization script /etc/init.d/rc and it calls other initialization scripts in turn. --> initはプロセスのグループを開始します。<tt>/etc/inittab</tt>ファイルは どのプロセスをシステムスタートするか指定します。これらのプロセスは initから直接継承される環境で動作します -- 典型的には<bf/getty/といったプロセス です(コンソールに<bf/login:/を表示するプログラム)。もしここでPPP接続を開始する ときは、init環境で動作していることを忘れてはなりません。システム初期化は ここで開始されるスクリプトです。Debian 1.3の初期化スクリプトは <tt>/etc/init.d/rc</tt>で、順番に初期化スクリプトが呼び出されます。 <p> <!-- The system contains many running servers (daemons) that may or may not use the default environment. Most servers are started from the initialization scripts and thus they have the init environment. --> システムは多くのサーバ(デーモン)を走らせています。これらはデフォルトの 環境で使うものもあればそうでないものもあります。ほとんどのサーバは 初期化スクリプトからこれらを開始し、そのためinit環境であると考えることが できます。 <p> <!-- When user logs in to the system, the environment is affected by the settings that are compiled into the programs, system wide initialization scripts and user initialization scripts. This is pretty complicated and the current situation is not completely satisfactory. It is totally different if user logs in from text console, XDM or from network. --> ユーザーがシステムにログインすると、環境はプログラム/システム広範の 初期化スクリプト/ユーザー初期化スクリプトに組み込まれる設定によって 反映されます。これはよい組み込まれかたですが現在の状態が完全に満足の いくものではありません。ユーザーがテキストコンソールからログインする 時とXDM、ネットワークからログインする時とではまったく違うものとなります。 <sect>Init <!-- Init --> <p> <!-- Init is a parent process for all the other processes of the system. Other processes inherit environment of the init process and the path is the init path in the rare case that no other path is set. --> Initは他のシステムプロセス全ての親プロセスです。他のプロセスは initプロセスの環境を継承して、パスはinitパスです(稀なケースでは その他のパスがセットされていない)。 <p> <!-- The 'init path' is fixed in the source of the init program and it is: --> 「<bf/init path/」はinitプログラムのソースに用意されています： <tscreen><verb> /usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin </verb></tscreen> <p> <!-- Note that init path does not contain /usr/local/bin. --> initパスには<tt>/usr/local/bin</tt>は含まれていないことに注目して下さい。 <p> <!-- All the programs that are started from /etc/inittab work in init environment, especially system initialization scripts in /etc/init.d (Debian 1.3). --> <tt>/etc/inittab</tt>から開始するプログラムは全てinit環境、特に <tt>/etc/init.d</tt>(Debian 1.3)のシステム初期化スクリプトで動作します。 <p> <!-- Everything that is started from system initialization scripts has init environment as default environment. For example, syslogd, kerneld, pppd (when started from startup), gpm and most importantly lpd and inetd have init environment and they do not change it. --> システム初期化スクリプトから開始するものは全てデフォルト環境として init環境を持っています。例えばsyslogd, kerneld, pppd(startupから始まった時)、 gpm、そして重要なlpd、inetdはinit環境を持っていて、その環境を変更することは しません。 <p> <!-- A group of programs are started from startup scripts but the PATH environment variable is explicitly set in the startup script. Examples are: atd, sendmail, apache and squid. --> プログラムのグループはstartupスクリプトから開始されPATH環境変数は startupスクリプトに明示的にセットされています。 例：atd, sendmail, apache、squid。 <p> <!-- There are other programs that are started from boot scripts but they change the path completely. One such example is cron. --> ブートスクリプトから開始するけれどパスを完全に変更する他のプログラムが あります。そのような例はcronです。 <sect>Login <!-- Login --> <p> <!-- In text console there is a getty program waiting for user login. It writes 'login:' and other messages. It is working in init environment. When getty gets user to log in to the system, it invokes the 'login' program. This program sets the user environment and invokes the shell. --> テキストコンソールにはユーザーログインを待つgettyプログラムがあります。 &dquot;login:&dquot;とメッセージを表示します。init環境で動作し、gettyが ユーザーをシステムにログインさせたら「login」プログラムを実行します。 このloginプログラムはユーザー環境をセットしシェルを実行します。 <p> <!-- Login program sets path as defined in /usr/include/paths.h. This 'login path' is different for root users and other users. --> ログインプログラムは<tt>/usr/include/paths.h</tt>にパスを定義しています。 この「ログインパス」はrootユーザーと他のユーザーでは違いがあります。 <p> <!-- for common users (_PATH_DEFPATH):--> 一般ユーザー用(<tt>_PATH_DEFPATH</tt>)： <tscreen><verb> /usr/local/bin:/usr/bin:/bin:. </verb></tscreen> <p> <!-- for root (_PATH_DEFPATH_ROOT):--> root用(<tt>_PATH_DEFPATH_ROOT</tt>)： <tscreen><verb> /sbin:/bin:/usr/sbin:/usr/bin </verb></tscreen> <p> <!-- Common user's path does not contain any sbin directories. However, it contains the current directory, '.', which is considered dangerous for the root user. Not even /usr/local/bin is available for the root user. --> 一般ユーザーのパスはsbinディレクトリを含んでいません。しかしカレント ディレクトリ(<bf/./)を含んでいます。カレントディレクトリはrootユーザー では危険です。rootユーザーにおいては<tt>/usr/local/bin</tt>にもパスを 通していません。 <p> <!-- Login path is often overwritten by shell initialization. However, it is possible to use other programs in /etc/passwd as user shells. For example, I have used the following line to start PPP when I log in using special user name. In this case, the pppd has exactly login path. --> ログインパスはシェル初期化によって上書きされることがあります。しかし ユーザーシェルとして<tt>/etc/passwd</tt>に他のプログラムを指定する ことも可能です。例えば特殊ユーザー名でログインした時PPPを開始する 以下のような行を使っています。このケースではpppdがログインパス として正しく書かれています。 <tscreen><verb> etu-ppp:viYabVlxPwzDl:1000:1000:Esa Turtiainen, PPP:/:/usr/sbin/pppd </verb></tscreen> <sect>シェル <!-- Shells --> <p> <!-- Often user processes are children processes of the shell mentioned in /etc/passwd for this user. Initialization files of shells often modify path. --> ユーザープロセスは<tt>/etc/passwd</tt>で書かれているシェルの子プロセスです。 シェルの初期ファイルはパスを修正することがあります。 <p> <!-- In login, the name of the shell is preceded with '-', for example bash is called as '-bash'. This signals to the shell that it is a 'login' shell. In this case, the shell executes the 'login' initialization files. Otherwise some lighter initialization is performed. Additionally, the shell checks if it is interactive - are the commands coming from file or interactive tty. This modifies the shell initialization so that a non-interactive non-login shell is initialized very lightly - bash do not execute any initialization file in this case! --> ログインではシェルの名前は<bf/-/を前置きします。例えばbashは<bf/-bash/のよう にして呼ばれます。これはシェル(つまり<bf/login/シェル)にシグナルを送ります。 この場合、シェルは<bf/login/初期化ファイルを実行します。そうでなければ ある 初期化が実行されます。 加えてシェルはそれがインタラクティブかどうかチェックします - ファイルや インタラクティブなttyからのコマンドです。これはシェルの初期化を修正して、 その結果インタラクティブではない(non-interactive)non-loginシェルが 初期化されます。bashはここではなんの初期化ファイルも実行しません。 <sect1>bash<label id="bash"> <!-- bash --> <p> <!-- As a normal login shell, bash 'sources' system-wide file /etc/profile, where the system environment and path can be set for bash users. However, it is not run when the system interprets the shell as non-interactive. The most important case is in rsh, where remote command is executed in the neighboring machine. The /etc/profile is not run and the path is inherited from rsh daemon. --> 通常のloginシェルとして、bashはシステム広範(system-wide)のファイル <tt>/etc/profile</tt>を使い(<bf/sources/)ます。このファイルはシステム環境と パスをbashユーザー用にセットします。しかしシステムがnon-interactiveとして 実施された時はこれは実行されません。もっとも重要なケースは、隣りのマシンで 実行されるリモートコマンドがrshで行われた場合です。<tt>/etc/profile</tt>は 実行されずパスはrshデーモンから継承されています。 <p> <!-- bash receives command line arguments -login and -i that can be used to set the shell as a login shell or interactive shell respectively. --> bashはコマンドライン引数<tt>-login</tt>と<tt/-i/を受け取ります。この 引数はそれぞれloginシェルあるはインタラクティブ(interactive)シェルとして シェルをセットするのに使われます。 <p> <!-- The user can overwrite values set in /etc/profile by creating a file ˜/.bash_profile, ˜/.bash_login or ˜/.profile. Note that just the first one of these is executed thus differing of the logic of csh initialization. ˜/.bash_login is not executed specially for login shells and if .bash_profile exists, it is not executed at all! --> ユーザーは<tt>˜/.bash_profile, ˜/.bash_login、˜/.profile</tt> ファイルを作ることで<tt>/etc/profile</tt>でセットされている値を上書きする ことができます(つまりユーザーの設定)。 これらのファイルのひとつめ(<tt>˜/.bash_profile</tt>)はcsh初期化の ロジックと違うことに注意して下さい。<tt>˜/.bash_login</tt>は loginシェルに関しては特に何も実行せず、また<tt>.bash_profile</tt>があると きは全く実行されません！ <p> <!-- If bash is used with name sh instead of the name bash, it emulates original Bourne shell initialization: it sources just files /etc/profile and ˜/.profile and just for login shells. --> もしbashが&dquot;bash&dquot;という名前の代わりにshとう名前として使用されて いると、オリジナルのBourne shell初期化をエミュレートします：その際のファイル は<tt>/etc/profile</tt>、<tt>˜/.profile</tt>そしてloginシェル用の ものです。 <sect1>tcsh <!-- tcsh --> <p> <!-- As a login shell tcsh executes the following files in this order: --> loginシェルとしてtcshは以下のファイルをこの順に実行します： <itemize> <item><tt>/etc/csh.cshrc</tt> <item><tt>/etc/csh.login</tt> <item><tt>˜/.tcshrc</tt> <item><tt>˜/.cshrc</tt>(もし<tt/.tcshrc/が見つからない時) <item><tt>˜/.history</tt> <item><tt>˜/.login</tt> <item><tt>˜/.cshdirs</tt> </itemize> <p> <!-- tcsh can be compiled to execute login scripts before cshrc scripts. Beware! --> tcshはcshrcスクリプトの前にloginスクリプトを実行するように組み込めること にも注意して下さい！ <p> <!-- Non-interactive shells execute just the *cshrc scripts. *login scripts can be used to set the path just once in the login. --> インタラクティブでないシェルは<tt/*cshrc/スクリプトを実行します。<tt/*login/ スクリプトはloginで一回だけパスをセットするのに使われます。 <sect>ユーザーIDの変更 <!-- Changing user ID --> <p> <sect1>su <!-- su --> <p> <!-- Command su sets a new user id to use. If no user id is given, root is used. --> suコマンドは新しいユーザーIDを使うためのものです。ユーザーIDを指定しないと rootが使われます。 <p> <!-- Normally su invokes a subshell with a different user id. With argument '-' (more recent synonyms -l or - -login) su invokes shell like login shell. However, it does not use login program to do this but uses a yet another built-in path for login 'simulation' (term used in the source code). It is: --> 普通、suは違うユーザーIDでサブシェルを実行します。引数<bf/-/(最近の シノニムは<tt>-l</tt>あるいは<tt>--login</tt>)で、ログインシェルのように シェルを実行します。しかしログインプログラムを使いません <p> <!--for normal users--> 通常のユーザー： <tscreen><verb> /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:. </verb></tscreen> <p> <!--for root user--> rootユーザー： <tscreen><verb> /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin </verb></tscreen> <p> <!--su makes many quite subtle environment changes as well. --> suは多くの細かい環境も変更します。 <sect1>sudo <!-- sudo --> <p> <!-- There is a group of commands that make use of super user commands safer. They allow better logging, user-based restrictions and usage of individual passwords. Most widely used is sudo. --> スーパーユーザーコマンドを安全に使うためのコマンドのグループが あります。よいログイン、ユーザーベースの制限、個々のパスワードの 使い方を可能にします。もっともよく使われているのは<bf/sudo/です。 <tscreen><verb> $ sudo env </verb></tscreen> <p> <!--executes command env as super user (if it is configured to allow it). --> はスーパーユーザーとしてコマンド<bf/env/を実行します(使えるように 設定されている時)。 <p> <!-- sudo command has again a different approach to path handling. It modifies the search path so that the current directory is always the last one. However, it does not modify PATH environment variable. 'sudo env' and 'env' give the same value for PATH variable. Sudo adds just couple of environment variables like SUDO_USER. --> sudoコマンドはパス操作の異なるアプローチをもっています。sudoは検索パスを 修正してカレントディレクトリは最後になります。しかしPATH環境変数は変更しま せん。<bf/sudo env/や<bf/env/はPATH変数と同じ値を返します。 sudoは<tt>SUDO_USER</tt>といった２つの環境変数を追加します。 <sect>ネットワークサーバ <!-- Network servers --> <p> <!-- Most network servers should not invoke subprocesses of any kind. For security reasons, their path should be minimal. --> ほとんどのネットワークサーバはある種のサブプロセスを実行しません。 セキュリティ的な理由からそれらのパスは最小限に押さえられています。 <p> <!-- An important exception is all the services that allow logging in to the system from network. This section describes what is the environment in these cases. If the command is executed in the remote machine with rsh it gets different path than if it is executed with ssh. Similarly, logging in with rlogin, Telnet or ssh is different. --> 重要な例外はネットワークからシステムにログインできるようにする サービスについてです。この章では、このケースにおける環境とは何かについて 解説していきます。rshを使ってリモートマシンでコマンドが実行されると sshで実行されるものとは違うパスになっていることなどを見ていきましょう。 同様にrlogin、telnet、sshでのログインの違いなども見ていきます。 <sect1>inetd <!-- inetd --> <p> <!-- Most network servers do not have process of their own waiting for requests all the time. This work is delegated to an Internet super server called inetd. Inetd listens for all the defined network ports and starts the appropriate server when there is an incoming request. This behaviour is defined in /etc/inetd.conf. --> ほとんどのネットワークサーバーは&dquot;常時リクエストを待っているプロセス &dquot;を持っていません。この動作は<bf/inetd/と呼ばれるInternet super serverに 一括して委任(delegated)されています。inetdは定義されたネットワークポートを 全て監視し、リクエストがあったときに適当なサーバーを開始します。この振る舞い は<tt>/etc/inetd.conf</tt>で定義されています。 <p> <!-- inetd is started from system startup scripts. It inherits just path of init process. It does not modify it and all the servers started from inetd has init path. An example of such a server is imapd, the server of IMAP post office protocol. --> inetdはシステム開始時のスクリプトから起動されていて、initプロセスの パスを継承しています。このパスを修正する必要はありません。またinetdから 開始する全てのサーバはinitパスを使います。そのようなサーバの例は<bf/imapd/ や<tt>IMAP post office protocol</tt>のサーバといったものです。 <p> <!-- Other examples of inetd processes are telnetd, rlogind, talkd, ftp, popd, many http servers and so on. --> inetdプロセスのその他の例は<tt>telnetd, rlogind, talkd, ftp, popd</tt> そしてhttpサーバなどです。 <p> <!-- Often usage of inetd is still complicated by using a separate tcpd program to start the real server. It is a program that makes additional security checks before starting the real application. It does not affect the path (not verified). --> 実際のサーバーを開始するために別々にtcpdプログラムを使う場合、inetdの使い方は 複雑です。tcpdは実際のアプリケーションを開始する前にそのセキュリティ をチェックするというプログラムで、パスに影響は与えません(確認していません)。 <sect1>rsh <!-- rsh --> <p> <!-- rsh daemon sets the path from _PATH_DEFPATH (/usr/include/paths.h) that is the same path that login program uses for normal users. Root will get the same path than the normal user. --> rshデーモンは<tt>_PATH_DEFPATH(/usr/include/paths.h)</tt>からのパスを セットします。これは通常ユーザーとしてloginプログラムが使うのと同じパスです。 rootは通常ユーザーと同じパスを得ます。 <p> <!-- Actually, rshd executes the command it gets with the command line: --> 実際にはrshdはコマンドラインで <tscreen><verb> shell -c command-line </verb></tscreen> <p> とします。 <!-- and shell is not a login shell. It is desirable that all the shells mentioned in /etc/passwd support -c option to give on the command line. --> またシェルはログインシェルではありません。<tt>/etc/passwd</tt>に書かれて いる全てのシェルはコマンドラインで与えられる<tt/-c/オプションをサポート しているほうが望ましいです。 <sect1>rlogin <!-- rlogin --> <p> <!-- Rlogin is invokes login to make the real login procedure. If you login with rlogin, you get the same path than in login. Most other ways to log in to a Linux computer do not use login. Note the difference with rsh. --> rloginは実際のログイン処理を行うためにloginを実行します。rloginを使って ログインするとloginと同じパスを得ます。Linuxコンピュータにログインするための その他の方法ではloginを使いません。rshとの違いに注意して下さい。 <p> <!--The login command actually used is --> 実際に使うloginコマンドは <tscreen><verb> login -p -h host-name user-name </verb></tscreen> <p> です。<tt>-p</tt>オプションは<tt>HOME, PATH, SHELL, TERM, MAIL, LOGNAME</tt> といった環境変数以外の環境を保存するオプションです。 <!-- -p preserves the environment except the variables HOME, PATH, SHELL, TERM, MAIL and LOGNAME. -h tells the remote host name for logging. --> <tt/-h/はログインするリモートホストの名前を指定するオプションです。 <sect1>telnet <!-- telnet --> <p> <!-- Telnet is similar than rlogin. It uses the login program and the command line to invoke it in a similar way. --> telnetはrloginに似ています。telnetはloginプログラムを使っていて コマンドラインも同じような方法で実行されます。 <sect1>ssh <!-- ssh --> <p> <!-- ssh has a path setting of it's own. It has a fixed path where it adds the directory where ssh is. Often this means that /usr/bin is in the path twice: --> sshはそれ自身のパス設定を持っています。sshがあるディレクトリを追加した ディレクトリです。これは<tt>/usr/bin</tt>がパスに2度出てくるということを 意味しています： <tscreen><verb> /usr/local/bin:/usr/bin:/bin:.:/usr/bin </verb></tscreen> <p> <!-- The path does not contain /usr/X11/bin and shell invoked by ssh command is not a login shell. Thus --> パスには<tt>/usr/X11/bin</tt>ディレクトリはありません。またsshコマンドによって 実行されるシェルはloginシェルではありません。こうして <tscreen><verb> ssh remotehost xterm </verb></tscreen> <p> <!-- never works and anything in /etc/profile or /etc/csh.cshrc can change this. You must always use explicit path /usr/bin/X11/xterm. --> では全く動作しません。<tt>/etc/profile</tt>あるいは<tt>/etc/csh.cshrc</tt> に書かれていることはこれを変更できてしまいます。そこで絶対パス <tt>/usr/bin/X11/xterm</tt>と入力しなければなりません。 <p> <!-- ssh searches environment variables of form VAR=VALUE from file /etc/environment. Unfortunately this causes some problems with XFree86. --> sshは<tt>/etc/environment</tt>ファイルかた<tt>VAR=VALUE</tt>フォーム の環境変数を検索します。残念なことにこれはXFree86で問題を生じます。 <sect>XFree86 <!-- XFree86 --> <p> <sect1>XDM <!-- XDM --> <p> <!-- XDM is the most common way to log in to a graphical terminal. It a bit looks like login but it is internally totally different. --> XDMはグラフィカルターミナルにログインするのによく使われる方法です。 一見するとloginのように感じられますが内部的には全く異なるものです。 <p> <!-- In directory /etc/X11/xdm there are configuration files that are executed on different login phases. Xstartup (and Xstartup_0 specially for screen 0) contains commands to be run after the user has logged in (commands are run as user root). --> <tt>/etc/X11/xdm</tt>ディレクトリには、ログインそれぞれで実行される設定 ファイルがあります。<tt/Xstartup/(&dquot;<tt>Xstartup_0</tt>&dquot; はスクリーン0用)はユーザーがログインした後で実行されるコマンドが書かれて います(コマンドはrootとして実行されます)。 <p> <!-- The path that is set for users is in /etc/X11/xdm/xdm-config. There are lines: --> ユーザー用にセットされたパスは<tt>/etc/X11/xdm/xdm-config</tt>にあります。 そこには <tscreen><verb> 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 </verb></tscreen> <p> といった行があります。 <!-- That will be a default path for normal and root users respectively. It is very important that /usr/bin/X11 is available for X users. If X user logs in to another machine to start and X client application, he should get /usr/bin/X11 to his path even he don't seem to come directly from X terminal. --> これらはそれぞれ通常ユーザーとrootのデフォルトパスです。Xユーザーなら <tt>/usr/bin/X11</tt>にパスが通っていることはとても重要です。もしXユーザー が他のマシンにログインしてXクライアントアプリケーションを起動する場合、 <tt>/usr/bin/X11</tt>はXターミナルから直接参照されないパスなので <tt>/usr/bin/X11</tt>を入力しなくてはいけません。 <p> <!-- After running Xstartup the XDM runs /etc/X11/Xsession that is run as the final user. Local configuration is meant to be done in /etc/environment that is sourced (included) from Xsession if available (Xsession is run with /bin/sh and thus /etc/environment must be a sh file). This clashes with ssh that supposes that /etc/environment is a file that contains just lines of form VAR=VALUE. --> Xstartupを走らせて、XDMは最終的なユーザー(final user)として <tt>/etc/X11/Xsession</tt>を走らせます。ローカル設定は <tt>/etc/environment</tt>にあり、もしこれがあればXsessionで使われます。 (Xsessionは<tt>/bin/sh</tt>から実行されます。つまり<tt>/etc/environment</tt> はshファイルである必要があります)。これはsshとクラッシュします。 sshは、<tt>/etc/environment</tt>は<tt>VAR=VALUE</tt>フォームの行を含んでいる ファイルとするからです。 <sect1>xterm -ls <!-- xterm -ls --> <p> <!-- By default the path for all the commands invoked from X window manager menus is the path inherited from XDM. To use something different it must be set explicitly. To start a terminal emulator with a path that is "normal" some special option must be used. In xterm the option -ls (login shell) must be used to get a login shell with path specified in shell login initialization files. --> デフォルトではX windowマネージャーのメニューから起動される全てのコマンドの パスはXDMから継承されています。違うものを使うなら正しくセットする必要があり ます。&dquot;通常の&dquot;パスを使ってターミナルエミュレータを起動するには、 特殊オプションを使います。xtermでは、シェルログイン初期化ファイルで指定され たパスでログインシェルを使うのに、<tt>-ls</tt>オプション(loginシェル)を使わ なければいけません。 <p> 訳注：xterm manページの-lsオプションの箇所を参照して下さい。 <!-- xterm -ls このオプションはxterm windowで開始するシェルはloginシェル であることを表しています(例：argv[0]のはじめの文字はダッシュ です。ユーザーの.loginあるいは.profileを読むようにします) +ls これは-lsオプションとは逆でxterm windowで開始するシェルは loginシェルではないことを表します(例：通常の「サブシェル」 です)。 --> <sect1>ウィンドウマネージャメニューとボタン <!-- Window manager menus and buttons --> <p> <!-- Window manager inherits environment of XDM. All the programs started by the window manager inherit the environment of the window manager. --> ウィンドウマネージャはXDMの環境を継承しています。ウィンドウマネージャに よって起動されるプログラムは全てウィンドウマネージャの環境を継承します。 <p> <!-- User shell environment does not affect the programs that are started from window manager buttons and menus. For example, if program is started from 'xterm -ls', it has the default environment of login shell but if it is started from menu, it has just environment of the window manager. --> ユーザーシェル環境はウィンドウマネージャのボタンやメニューから起動する プログラムに影響しません。例えば<bf/xterm -ls/から実行したプログラムは ログインシェルの環境を使い、メニューから起動したプログラムは ウィンドウマネージャの環境を使います。 <sect>cron、atコマンドについて <!-- Delayed commands cron and at --> <p> <sect1>cron <!-- cron --> <p> <!-- Cron is a command that executes commands periodically as specified in /etc/crontab and user-defined crontabs. In Debian 1.3 there is a standard mechanism to execute commands in /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly. --> cronは<tt>/etc/crontab</tt>やユーザーが定義したcrontabで指定されたコマンド を定期的に実行するためのコマンドです。Debian 1.3では <tt>/etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly</tt>を使います。 <p> <!-- Cron is started from boot scripts but it seems to change it's PATH to a pretty strange one: --> cronはブートスクリプトから開始しますが、cronのパスがおかしいようです： <tscreen><verb> /usr/bin:/binn:/sbin:/bin:/usr/sbin:/usr/bin </verb></tscreen> <p> <!-- THIS IS LIKELY A BUG IN CRON. This is the init path where there is /usr/bin:/bin written over the beginning without terminating 0! This bug does not exist in all the systems. --> <bf>これはcronのバグです</bf>。これはterminating 0なし(without terminating 0) ではじめに上書きされた<tt>/usr/bin:/bin</tt>があるinitパスです！このバグは 全てのシステムにあるわけではありません。 <p> <!-- In crontab there can be PATH definition. In Debian 1.3 there is the following default line in the beginning of /etc/crontab: --> crontabでPATH定義をすることができます。Debian 1.3を使っているなら <tt>/etc/crontab</tt>のはじめに以下の行があります： <tscreen><verb> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin </verb></tscreen> <p> <!-- Because of this, the PATH of crond program is never used in user programs. All the scripts in /etc/cron.* directories get this path by default. This path is used even if a program is executed as non-root. --> このため、crondプログラムのパスはユーザープログラムで使われることは 決してありません。<tt>/etc/cron.*</tt>ディレクトリの全スクリプトは デフォルトでこのパスを参照します。プログラムがroot以外で実行された時でも このパスが使用されます。 <sect1>at <!-- at --> <p> <!-- at is a command that can be used to run a one-time program at specific time. --> atは特定の時間に一度だけプログラムを実行するのに使われます。 <p> <!-- atd is run using init path. However, the user programs are always run in the user environment using sh command. Therefore the usual shell overwrites apply. Look the chapter on bash. --> atdはinitパスを使います。しかしユーザープログラムは常にshコマンドを使った ユーザー環境で実行されます。そこで通常のシェル上書き(usual shell overwrites) が行われます。<ref id="bash" name="bash">の章を参照して下さい。 <sect>いくつかの例 <!-- Some examples --> <p> <sect1>magicfilter <!-- magicfilter --> <p> <!-- magicfilter is a common tool to manipulate files for printer. It analyzes the type of the file to be printed and invokes a filter script to make appropriate pretty-printing. These scripts are invoked from lpd that is started from /etc/init.d/lpd that is started from init. Thus, the path is that of init. That does not contain /usr/bin/X11! --> <bf>magicfilter</bf>印刷ファイルを操作するためのツールです。 印刷するためのファイルタイプを解析して、適当なちょっとよい印刷 (pretty-printing)を行うためのフィルタスクリプトを実行します。 これらのスクリプトはlpd(<tt>/etc/init.d/lpd</tt>)から実行されます。 lpdはinitから開始します。つまりmagicfilterのパスはinitのもので、 <tt>/usr/bin/X11</tt>にはパスは通っていません！ <p> <!-- You might want to insert printing of PDF files to magicfilter. It is possible to do this by using /usr/bin/X11/xpdf. Now you must remember to insert full directory path to the file name because magicfilter would not find it otherwise. Most programs used in magicfilter do not need full path, because they are on /bin or /usr/bin. --> magicfilterにPDFファイルの印刷を入れたいという場合は、 <tt>/usr/bin/X11/xpdf</tt>を使ってこれを行うことができます。magicfilterは initから継承されたパス以外のプログラムは見つけられないので、ファイル名を フルパスで書く必要があります。magicfilterで使われるほとんどのプログラムは、 <tt>/bin、/usr/bin</tt>にあるので、フルパス必要としません。 <p> 訳注： 「The Linux Printing HOWTO」佐藤亮一(GFG02131@niftyserve.or.jp)さん訳の &dquot;6. 適切なマジックフィルターの入手法&dquot;を参照して下さい。 <url url="http://jf.gee.kyoto-u.ac.jp/JF/JF.html" name="JFサイト">から入手 できます。 <!-- 参照： http://serpent.phys.wani.osaka-u.ac.jp/~shimizu/magicfilter.html --> <sect1>Xアプリケーションからの印刷 <!-- Printing from X applications --> <p> <!-- You may use PRINTER environment variable to show what is the printer that you are using. However, you may notice that in some cases in X applications it is sometimes lost. --> <tt/PRINTER/環境変数はどのプリンタを使っているかを示すのに使われます。 しかしXアプリケーションではこれが使われないことがあることに注意して 下さい。 <p> <!-- You must remember that if the X session is started from XDM, the window manager has never evaluated your shell login scripts. All the X applications that you have started from xterm have your PRINTER variable. However, if the same application is started from menu or window manager button, it does not contain your PRINTER variable. --> XセッションがXDMから始まった場合は、ウィンドウマネージャはシェルlogin スクリプトを全く評価しません。xtermからスタートしたXアプリケーション は<tt/PRINTER/変数を引き継いでいます。しかし、もしメニューやウィンドウ マネージャのボタンから同じアプリケーションを起動しても<tt/PRINTER/変数は 引き継ぎません。 <p> <!-- In some cases this can be inherited to an even lower layer: for example a Netscape helper application can have or have not your PRINTER definition. --> ある場合、これは下位のレイヤ(lower layer)に継承することができます。 例えばNetscape補助アプリケーションは<tt/PRINTER/定義を引き継ぐことも 引き継がないこともできます。 <sect>セキュリティの考察 <!-- Security concerns --> <p> <!-- The path is sometimes a big security problem. It is a very common way to hack into a system using some mistakes in path settings. It is easy to make Trojan horse attacks if hacker gets root or other users to execute his versions of commands. --> パスには重要なセキュリティ問題があります。パス設定の間違いを悪用して、システム にクラック(原文：hack)するのによく使われる方法です。もしクラッカー (原文：hacker)がroot、一般ユーザーでクラッカーのコマンドを実行すると、簡単に 「トロイの木馬(Trojan horse)」攻撃がなされてしまいます。 <p> <!-- A common mistake in the past (?) was to keep '.' in the root's path. Malicious hacker makes program 'ls' in his home directory. If root makes --> 昔(?)のよくあったミスはrootのパスに<tt/./(カレントパス)を入れる といったものです。悪意のあるハッカー(クラッカー)は彼のホームディレクトリ でプログラム<tt>ls</tt>を作り、もしrootが <tscreen><verb> # cd ~hacker # ls </verb></tscreen> <p> <!-- he executes ls command of hacker's.--> と実行するとクラッカーのlsコマンドを実行してしまいます。 <p> <!-- Indirectly, this same applies to all the programs that are executed as root. Any of the important daemon processes should never execute anything that some other user can write into. In some systems, /usr/local/bin is allowed to contain programs with less strict security screening - it is just removed from the path of the root user. However, if it is known that some daemon executes 'foo' using path '/usr/local/bin/:...', it may be possible to cheat daemon to execute '/usr/local/bin/foo' instead of '/bin/foo'. Likely anybody who can write to '/usr/local/bin' is able to break into the system. --> 間接的にこれはrootとして実行されるプログラム全てに適用されます。 重要なデーモンプロセスでは他のユーザーが書き込めないようにするべきです。 <!-- (訳注：imapdのセキュリティホール参照) --> あるシステムでは<tt>/usr/local/bin</tt>にセキュリティ的に不十分な プログラムでも置くことができます - そのためrootユーザーのパスから <tt>/usr/local/bin</tt>を除外しておくべきです。しかしもしあるデーモンが パス<tt>/usr/local/bin/:...</tt>を使ったfooを実行していると、 <bf>/bin/foo</bf>ではなく<bf>/usr/local/bin/foo</bf>を実行することも 可能です。そして<bf>/usr/local/bin</bf>に書き込めるユーザーはだれでも システムを壊すことができてしまいます。 <p> <!-- It is very important to consider in what order the directories are in the path. If /usr/local/bin is before /bin, it is a security risk - if it is after, it is not possible to overwrite command /bin/foo with some localized modification in /usr/local/bin/foo. --> パスのディレクトリの順番に注意を払うのも大変重要です。例えば、 <tt>/usr/local/bin</tt>が<tt>/bin</tt>の前にあるとセキュリティリスクが 生じます - もし<tt>/bin</tt>の後に<tt>/usr/local/bin</tt>があれば、 <tt>/bin/foo</tt>コマンドを<tt>/usr/local/bin/foo</tt>とローカルに修正した もので上書きすることはできません(つまりこの方がセキュリティ的に安全です)。 <p> <!-- In Linux it should be remembered that the path evaluation is done in the operating system call level. Everywhere where an executable file path is given you can give a short name that is searched at least from /bin and /usr/bin - likely from many other places as well. --> Linuxでは、パスの評価がオペレーティングシステムコールレベル(operating system call level)で行われていることを思い出して下さい。 実行ファイルのパスが与えられているところならどこでも、(少なくとも) <tt>/bin、/usr/bin</tt>から検索される短い名前(short name)が与えられます - 他の場所でも同様です。 <sect>問題のデバッグの仕方は？ <!-- How to debug problems? --> <p> <!-- The basic command to read environment is /usr/bin/env. --> 環境を表示(read)するための基本的なコマンドは<tt>/usr/bin/env</tt>です。 <p> <!-- It is possible to use /proc directory to find out path of any program. First you must know the process number - use ps command to get that. For example, if xterm is process number 1088, you can find it's environment with command --> あるプログラムのパスを見つけるのに<tt>/proc</tt>ディレクトリを使うことも 可能です。はじめにプログラムのプロセス番号を調べて下さい - psコマンドを 使います。例えばxtermのプロセス番号が1088なら、 <tscreen><verb> # more /proc/1088/environ </verb></tscreen> <p> としてxtermの環境を表示することができます。 <!-- This does not work with daemon processes like xdm. To access environment of system processes or other user processes, root access is required. --> これはxdmといったデーモンプロセスでは動作しません。システムプロセス、 他のユーザープロセスの環境にアクセスするにはrootアクセスが必要です。 <p> <!--To debug Netscape, you can create a script /tmp/test:--> Netscapeをデバッグするために、<tt>/tmp/test</tt>スクリプトを作ることも できます： <tscreen><verb> $ cat > /tmp/test #!/bin/sh /usr/bin/env > /tmp/env ^d $ chmod +x /tmp/test </verb></tscreen> <p> <!-- Then set some helper application, for example RealAudio, audio/x-pn-realaudio to call program "/tmp/test". When you try to browse some RealAudio link (something from http://www.realaudio.com/showcase), Netscape calls the dummy program that stores environment to /tmp/env. --> そして適当な補助アプリケーションをセットします(例えばaudio/x-pn-realaudioに RealAudio)。(<tt><htmlurl url="http://www.realaudio.com/showcase" name="http://www.realaudio.com/showcase"></tt>の)RealAudioリンクを閲覧して みて下さい。Netscapeは<tt>/tmp/env</tt>にストアされている環境のダミー プログラムを呼び出します。 <sect>全ユーザーが同じパスを得るための方法 <!-- Some strategies to get the same path for all the users --> <p> <!-- The most important settings is possible to set in the global shell initialization files for login shells: /etc/csh.login for tcsh and /etc/profile for bash. --> もっとも重要な設定は、loginシェル用のグローバルシェル初期化ファイルに セットすることも可能です：<tt>/etc/csh.login</tt>(tcsh)、 <tt>/etc/profile</tt>(bash)。 <p> <!-- Exceptions that do not get the right path from these files are rsh commands, ssh commands, menu items from X window manager that do not explicitly start login shell, commands invoked from inittab, cron jobs, daemons jobs like magic filters started from lprd, WWW CGI scripts, and so on. --> これらのファイルから正確なパスを得ないといった例外として： rshコマンド、sshコマンド、(loginシェルをはっきりと開始しない)X window manager のメニューアイテム、inittabから実行されるコマンド、cronジョブ、lprdから起動 されるmagicフィルタのようなデーモンジョブ(daemons jobs)、WWW CGIスクリプト などがあります。 <p> <!-- If the path is set in /etc/csh.cshrc, the path is right even when rsh or ssh execute command in remote machine with account using tcsh/csh. However, it is not possible to set path if account uses bash/sh. --> もし<tt>/etc/csh.cshrc</tt>にパスがセットされていると、 tcsh/cshを使ったアカウントのリモートマシンでrsh、sshからコマンドを実行 した時でも、正しいパスが通っています。 <p> <!-- It is possible to combine path setting to one file, for example to a file /etc/environment-common. There we write: --> 1つのファイル(例えば<tt>/etc/environment-common</tt>)にパス設定を まとめることも可能です。例えば、 <tscreen><verb> ${EXPORT}PATH${EQ}/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/usr/local/bin:/usr/games:. </verb></tscreen> <p> とします。 <!-- This can be used from /etc/csh.login (for tcsh and csh) --> これは<tt>/etc/csh.login</tt>(tcsh、csh)から使われます： <tscreen><verb> set EQ=" " set EXPORT="setenv " source /etc/environment-common </verb></tscreen> <p> <!-- And from /etc/profile (for bash, doesn't work for ordinary sh) --> また<tt>/etc/profile</tt>(bash、オリジナルshとして動作しない)： <tscreen><verb> EQ='=' EXPORT="export " . /etc/environment-common </verb></tscreen> <p> <!--And from /etc/environment (for XDM) --> <tt>/etc/environment</tt>(XDM用)： <tscreen><verb> EQ="=" EXPORT="export " . /etc/environment-common </verb></tscreen> <p> <!-- This strategy works mostly but ssh will complain of the lines in /etc/environment (and defined environment variables EQ and EXPORT). And still, rsh commands executed with bash won't get this path. --> この方法はだいたい動作しますが、sshは<tt>/etc/environment</tt>(環境変数EQ、 EXPORT定義)の行で不平を言うかもしれません。またbashで実行するrshコマンド はこのパスを継承しないかもしれません。 <sect>謝辞 <!-- Acknowledgements --> <p> <!-- One reason to start writing this document was the big frustration of Ari Mujunen. Juha Takala gave some valuable comments. --> このドキュメントを書き始めた理由のひとつはAri Mujunen氏(amn@bigbang.nfra.nl) の大きな不満があったということです。 Juha Takala氏には価値あるコメントをいただきました。 </article>