<!doctype linuxdoctr system>

<!-- 
TITL: PATH HOWTO
FNAM: Path.euc
CATG: LDP mini-HOWTO
AUTH: Esa Turtiainen <etu@dna.fi>
TRNS: 伊佐冶 哲 <isaji@mxu.meshnet.or.jp>
COPY: GPL2
NOTE: 
CHKR: isaji@mxu.meshnet.or.jp
STAT: Waiting
-->

<article>

<title>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 &percnt;ENV, you can set PATH as
&dollar;ENV{PATH}="/bin".
-->
Cプログラムは<tt/setenv()/ライブラリコールを環境の変更に使います。Perlは
配列 <tt>&percnt;ENV</tt>に環境を持っていて、PATH
を<tt>&dollar;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
&tilde;/.bash_profile, &tilde;/.bash_login or &tilde;/.profile. Note
that just the first one of these is executed thus differing of the
logic of csh initialization. &tilde;/.bash_login is not executed
specially for login shells and if .bash_profile exists, it is not
executed at all!
-->
ユーザーは<tt>&tilde;/.bash_profile, &tilde;/.bash_login、&tilde;/.profile</tt>
ファイルを作ることで<tt>/etc/profile</tt>でセットされている値を上書きする
ことができます(つまりユーザーの設定)。
これらのファイルのひとつめ(<tt>&tilde;/.bash_profile</tt>)はcsh初期化の
ロジックと違うことに注意して下さい。<tt>&tilde;/.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 &tilde;/.profile and just for login shells.
-->
もしbashが&dquot;bash&dquot;という名前の代わりにshとう名前として使用されて
いると、オリジナルのBourne shell初期化をエミュレートします：その際のファイル
は<tt>/etc/profile</tt>、<tt>&tilde;/.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>&tilde;/.tcshrc</tt>
<item><tt>&tilde;/.cshrc</tt>(もし<tt/.tcshrc/が見つからない時)
<item><tt>&tilde;/.history</tt>
<item><tt>&tilde;/.login</tt>
<item><tt>&tilde;/.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&lowbar;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&lowbar;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>
&dollar;{EXPORT}PATH&dollar;{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>
