ここでは、システム全体の設定を行う /etc などのファイルと、各ユーザのホームディレクトリに置くドットファイルの説明をします。ついでに /dev についても少しだけ書いてあります。
/etc のファイル構成は OS によって大きく違います。以下は FreeBSD について書いたものなので、他の OS を使っている方は参考程度にとどめて下さい。
一方、各ユーザのドットファイル群については、他の OS でもほとんど同じだと思います。
/etc/aliases メールアドレスのエイリアス設定ファイル (sendmail)
このファイルは、sendmail 用エイリアス (別名) 設定ファイルである。qmail など、sendmail 以外の MTA を利用している場合は関係ない。
基本的な書式は、
である。例えば foo.com の /etc/aliases を
とすると、hoge@foo.com 宛のメールは実際には fuga@foo.com に届けられる。また、
だと、hoge@foo.com宛のメールは /dev/null に送られる (つまりどこにも届かない)。また、
hoge: "|/usr/bin/mail-program"
とすると、hoge@foo.com 宛にメールが届いたときに /usr/bin/mail-program が実行される。mail-program は標準入力からメールの内容が送られてくるので、それを処理すればよい。fml や majordomo などのメーリングリストソフトは、このようにメールが届いたときにプログラムを実行することで実現されている。
/etc/aliases の変更後は newaliases コマンドを実行しないと、新しい内容が反映されない。
自動的に実行させたいプログラムを書いておく。/etc/daily、/etc/weekly、/etc/monthly などはここから実行される。
1分おきに cron というデーモンが /etc/crontab の更新をチェックするので、更新後はリブートなどはする必要はない。
各ユーザや root が crontab コマンドを実行して登録してもよいが、サイト固有の定時起動するコマンドは、このファイルに書いておく方が管理がしやすいだろう。
OS のブート時に、ここに書かれた通りマウントが行われる。例えば、
/dev/sd0s1a / ufs rw 1 1
/dev/sd0s1f /usr ufs rw 2 2
/dev/sd0s1e /var ufs rw 2 2
と書くと、ブート時に
# mount /dev/sd0s1a /
# mount /dev/sd0s1f /usr
# mount /dev/sd0s1e /var
が行われる。また、/etc/fstab に記述しておくことで、mount コマンドの引数を省略できる。例えば CD-ROM をマウントする際、
% mount -o rdonly -t cd9660 /dev/cd0c /cdrom
としているなら、/etc/fstabに
/dev/cd0c /cdrom cd9660 ro,noauto 0 0
と書いておくと、
だけでマウントすることができる。
一般ユーザの権限でマウントさせたい場合は、sudo を使うとよいだろう。Linux では/etc/fstab にオプションを書くことで指定のユーザにマウントを行う権限を与えられるそうだ。
なお、Solaris では /etc/fstab ではなく /etc/vfstab である。
書式は、
グループ名:パスワード:グループID(gid):グループに属するユーザ[...]
である。例えば、
は
「wheel グループは GID が 0 でパスワードはなし。wheel グループに属するユーザは root と user である」
という意味。
FreeBSD で、特に意味を持つグループは、以下の通り。
- wheel … su コマンドでスーパーユーザになれる
- operator … shutdown コマンドが実行できる
- network … ppp コマンドが実行できる。
- nobody … 最も実行権限が弱いグループ
自分の属するグループを知りたい場合、id コマンドを使う。
/etc/host.conf 名前を解決する際に、DNS と /etc/hosts の優先順位を決める。
www.foo.com などのホスト名を 123.124.125.126 などの IP アドレスに変換するには、DNS サーバに問い合わせるか、あるいは /etc/hosts を参照する、という2種類の方法がある。host.conf でどちらを優先するか設定することができる。
と書いておくと、まず /etc/hosts を参照し、それでも解決できないものは DNS サーバに問い合わせる。
とすると、逆の動作になる。さらに NIS を使っている場合には
と書いておく。普通は
と書いておく方がよいだろう (FreeBSD のデフォルトはこうなっているはず)。
nslookup コマンドは、/etc/host.conf を無視し、常に DNS サーバに問い合わせる (/etc/hosts は参照しない) ことに注意。
/etc/hosts ホスト名と IP アドレスの対応表を書いておくファイル
ここに IP アドレスとホスト名の対応を書いておくことで、いちいち DNS サーバに問い合わせなくても、IP アドレスとホスト名の相互変換ができる。
133.144.155.166 host.domain.ac.jp host
と書いておくと、telnet や ping などで host.domain.ac.jp と指定するかわりに、host だけでホストの特定ができる。
ただし、/etc/host.conf の中で hosts を bind より先に書いておかなくてはいけない。
このファイルを更新した場合は
として更新内容を反映させなければならない。
でもよい。
このファイルの役割については、inetd の項を参照してほしい。
シェル、ユーザ ID、パスワードなどを記録してある「本当の」パスワードファイル。いわゆるシャドウパスワードである。一般ユーザは見ることができない。詳しくは /etc/passwd の項を参照してほしい。
BSD 系 UNIX ではシャドウファイルは /etc/master.passwd だが、SystemV 系・Linux 系では /etc/shadow などとなっている。
なお、/etc/master.passwd は直接編集してはいけない。root になって vipw コマンドを使うこと。もしうっかり編集してしまったら、必ず pwd_mkdb コマンドで /etc/passwd・/etc/pwd.db・/etc/spwd.db を再構築すること (編集後に pwd_mkdb コマンドの実行を忘れなければ直接編集しても構わない)。
一般ユーザが見ることのできるパスワードファイル。例えば
user:*:1001:1001:Yamada Taro:/home/user:/usr/local/bin/tcsh
この行は、
- ユーザ名は user
- パスワードは秘密 (後述)
- ユーザ ID は 1001
- グループ ID は 1001
- 本名は Yamada Taro (GECOS フィールド)
- ホームディレクトリは /home/user
- ログインシェルは /usr/local/bin/tcsh
であることを示している。
パスワードファイルといっても、パスワードは書かれていない環境もある。昔は /etc/passwd に直接暗号化されたパスワードが入っていた。しかし、現在はコンピュータの高速化により、総当たりでパスワードを解読することも不可能ではなくなったので、暗号化されたパスワードを一般ユーザに公開するのは危険になってしまったわけである。
そこで、暗号化されたパスワードは別のファイルに記録して root 以外には見えないようにし、それ以外の情報を /etc/passwd に置いておくことになった。この仕組みをシャドウパスワードという。BSD 系 UNIX のシャドウパスワードファイルは /etc/master.passwd、一方 SystemV 系・ Linux 系 UNIX のシャドウパスワードファイルは /etc/shadow である。
FreeBSD・NetBSD・OpenBSD では、パスワードファイルは標準でシャドウ化されている。一方 Linux はディストリビューションによって違う (/etc/passwd に暗号化されたパスワードが書かれているものもある)。
まとめると、BSD 系ではパスワードに関して
- 一般ユーザが見ることができる /etc/passwd
- シャドウパスワード /etc/master.passwd
- 高速化のため、/etc/passwd を DB 化した /etc/pwd.db
- 高速化のため、/etc/master.passwd を DB 化した /etc/spwd.db
という4つのファイルがある。BSD 系では、エディタで直接 /etc/passwd や /etc/master.passwd を編集してはいけない。なぜなら、これらの4つのファイルの内容に不整合が生じるからである。編集する場合は、root なら vipw コマンド、一般ユーザなら chsh などを使うこと。さすれば4つのファイルを自動的に更新してくれる。
もしこれらのファイルを間違えていじってしまった場合は、pwd_mkdb コマンドで/etc/master.passwd が残っていれば、他の3つのファイルを作成できる。
一方、SystemV 系・Linux 系では、
- /etc/passwd のみ (シャドウ化されていない)
- /etc/passwd と /etc/shadow の2本立て (シャドウ化されている)
のどちらかである。こちらの方はエディタで直接 /etc/passwd・/etc/shadow を編集してよい (管理用コマンドがあるなら、もちろんそれを使ってもよい)。
ちなみに /etc/passwd は一般ユーザが見られるようにしないといけない。なぜなら、ファイル・ディレクトリの所有者・所有グループは、ユーザ名・グループ名でなく、UID・GID という番号で記録されているからである。つまり、/etc/passwd が一般ユーザから見えないと、ls -l を実行したときに所有者・所有グループを見ることができず、ただの数字 (UID・GID)しか表示されない。また、finger で特定ユーザの GECOS フィールド (本名を記録するフィールド) も見えなくなる。
/etc/pwd.db /etc/passwd をデータベース化したもの。BSD 系のみ。
ls や finger などが実際に参照するのはこちらの方。なぜなら、データベース化されており、高速に参照できるからである。
キーボード、ホスト名、ネットワーク、端末などの各種設定を行う。
FreeBSD 3.0-RELEASE 以降では、/etc/defaults/rc.conf にデフォルト設定が書いてあり、/etc/rc.conf には変更したい設定のみを記述する。つまり、/etc/defaults/rc.conf を編集しては *いけない*。また、
# cp /etc/defaults/rc.conf /etc/rc.conf
として、/etc/rc.conf を編集しても *いけない*。
例えばマシンブート時に sendmail を自動的に起動したかったら、/etc/rc.conf に
という行を追加するだけでよい (/etc/defaults/rc.conf を編集する必要はない)。
この部分は /stand/sysinstall で設定することもできる。
DNS サーバの IP アドレスを書いておくファイル。DNS サーバとは、ホスト名を IP アドレスに変換してくれるサーバである。
TCP/IP では、ホスト名に対応する IP アドレスがわからないと、そのホストに到達することができない。telnet やブラウザなどでホスト名を利用するときは、ユーザからは見えないが、毎回 DNS サーバにホスト名からIP アドレスへの変換を依頼し、その上で目的のホストとの通信を行っている。
DNS サーバへの問い合わせ自体も TCP/IP を使って実現されているので、DNS サーバだけは必ず IP アドレスを書いておかなくてはいけない。書式は
- nameserver ネームサーバのIPアドレス
- domain そのマシンが属するドメイン名
である。例えば /etc/resolv.conf が
nameserver 127.0.0.1
domain subnet.net.ac.jp
となっているとしよう。ここで
とすると、telnet コマンドは OS に foo.bar.com を IP アドレスに変換するよう依頼する。OS は /etc/resolv.conf に書かれた DNS サーバの IP アドレス (127.0.0.1) にアクセスし、foo.bar.com を IP アドレスに変換する。そして telnet コマンドは、受け取った IP アドレスに接続するわけである。ここで
のようにドメイン名を省略したホスト名を指定すると、
- foo というホスト名の変換を DNS サーバに依頼
- 失敗したら foo.subnet.net.ac.jp で再度挑戦
となる。
HTTP のポート番号は 80 番、POP3 は 110 番と決まっている。これは「well known port」と呼ばれ、IANA という機関が管理している。/etc/services は、ポート番号とサービス名の対応を記したファイルである。
例えば telnet コマンドで
と直接ポート番号を指定してもよいが、
とサービス名で指定することもできる。これは /etc/services に
http 80/tcp www www-http #World Wide Web HTTP
と記述されているからである。この行は
http のポートは 80 で、TCP であり (UDP ではなく)、サービス名の別名として www、www-http が使える
という意味である。よって、
% telnet hostname 80
% telnet hostname www
% telnet hostname www-http
はいずれも同じことを意味する。このファイルは、netstat や tcpdump の出力、ライブラリ関数 getservbyname(3) などから利用される。
/etc/shadow SystemV 系・Linux 系のシャドウパスワードファイル
暗号化したパスワードなどが記録してあるパスワードファイル。いわゆるシャドウパスワードである。一般ユーザは見ることができない。詳しくは /etc/passwd の項を参照してほしい。
少なくとも LASER5 Linux 6.0 では、/etc/shadow には
- ユーザ名
- 暗号化されたパスワード
- アカウントの有効期限に関する情報
を記述する。
ログインシェルにできるプログラムをフルパスで記述する。ここに登録されていないプログラムをログインシェルにすることはできない。普通、
/bin/sh
/bin/csh
/usr/local/bin/bash
/usr/local/bin/tcsh
などと、各種シェルを登録しておく。bash や tcsh などの高機能シェルが登録されていなかったら、管理者に文句を言おう。せっかく便利なシェルがあるのに、わざわざ sh や csh などの低機能なシェルを使う必要はない。
もし、/etc/shells に使いたいシェルが登録されていなかった場合は、ログインシェルとしては使えないが、ログインした後に
などと好きなシェルを起動すればよい。
/etc/spwd.db /etc/master.passwd をデータベース化したもの。BSD 系のみ。
/dev/null への出力は、ディスクに書き込まれることはなく、全て破棄される。例えばコマンド hoge の実行時間を計りたいときは
でなく、
とすることで、画面出力などの余分な時間を取り除き、純粋な実行時間を知ることができる。
また、/dev/null を読むと、いきなり EOF が現れる。よって、
% cat /dev/null > file
% cp /dev/null file
は、0 バイトのファイル file を作る、あるいは既に存在する file を 0 バイトにする効果がある。
カーネル (/kernel) を作成するには、カーネルコンフィグレーションファイルを編集し、コンパイルすればよい。GENERIC はデフォルトのカーネルの設定ファイルで、FreeBSD のインストール直後には GENERIC をコンパイルしたカーネルが使われている。
カーネルの再構築を行うには
# cd /usr/src/sys/i386/conf/
⇒ Pentium アーキテクチャの場合は i386
# cp GENERIC MYKERNEL (ファイル名は何でもよい)
# config MYKERNEL
Kernel build directory is ../../compile/MYKERNEL
# cd ../../compile/MYKERNEL
# make depend (カーネルの依存関係をチェック)
# make (カーネルのコンパイル)
# make install
とする。
カーネルコンフィグレーションファイルの各オプションの説明が書かれている。実際には同時に設定できないオプションが書かれているため、LINT をそのままカーネルコンフィグレーションファイルとすることはできない。また、全ての設定について完全に網羅しているわけではない。
root の login の許可・不許可の設定は「secure」という文字列が書いてあるかどうかで決まる。例えば
ttyv1 "/usr/libexec/getty Pc" cons25 on secure
と書いてあると、root としてログインできる。一方
ttyv1 "/usr/libexec/getty Pc" cons25 on
と、「secure」を削ると、root としてログインすることはできない。
一般的に root 権限が欲しかったら、最初は一般ユーザとしてログインし、その後 su コマンドを実行して root になればよい。
このファイルを参照するのは init である。ファイルを書き換えたら
で新しい内容が反映される。
ログイン中のユーザ名と、使用中の端末名が書かれている
X サーバに Accelarated-X を使っている場合は、ここに設定が書かれる。Accelarated-X は商用の X サーバ。
XF86Setup や XF86Config を実行して X サーバの設定をすると、ここに設定用ファイルが置かれる。
startx や xdm で X サーバを起動したときには、このファイルが読み込まれる。
コンソールでのキーボードマップの定義。X 上でのキーボード設定とは関係ない。US101 キーボードなら us.iso、日本語 106 キーボードなら jp.106、日本語 106 キーボードの Capslock と Ctrl キーの位置を交換したものが jp.106x。
/etc/rc.conf に keymap="jp.106x" などと書いておくと、OS のブート時に自動的に kbdcontrol コマンドが実行され、キーボードマップが設定される。
bash実行時に自動的に読まれるファイル。このファイルが存在しなかった場合は、~/.profileが読まれる。
~/.cshrc csh・tcsh 用設定ファイル
csh・tcsh の起動時に自動的に読まれる設定ファイル。sh・bash とは全く関係がない。
設定ファイルと言っても、内容はただの csh スクリプトである。~/.cshrc を更新したときは、一度ログアウトしログインし直すか、あるいは
とすればよい。
ここでエラーが起こった場合は
とすれば、どこでエラーが発生しているかがわかる。
普通、このファイルの中では、常に設定しておきたいこと、例えば
- set コマンドでパスの設定
- alias コマンドで alias の設定
- set コマンドでシェル変数の設定
- setenv コマンドで環境変数の設定
- その他シェルの設定など (complete・umask など)
などを書いておく。
なお、tcsh を使っている場合でも、~/.tcshrc が存在しない場合は ~/.cshrc が読み込まれる。
メールを自動的に転送する。転送先のメールアドレスを書いておけば、自動的にそのメールアドレスに転送される。ここでユーザ名「usernmae」というアカウントを例にとると、~username/.forwardに
と書いておくと、username 宛に届いたメールは hoge@fuga.com に転送される。複数のメールアドレスに転送したい場合は、
hoge@fuga.com,foo@bar.ac.jp
とカンマで区切ることで記述できる。
届いたメールを hoge@fuga.com に転送したいが、最初に届いたホストにもメールを残しておきたい場合は、
と書いておく。先頭の「\」は、転送先の展開を抑制を意味する。もし
と書いてしまうと、username に届いたメールは username 自身に再度送られるが、再び ~username/.forward が参照されて、usernmae に配送される。この繰り返しで無限ループに陥ってしまう (実際は数回ループするとエラーとなり停止する)。
また、メールが届くと自動的にプログラムを実行させることもできる。これを利用して、メールが届くとメール振り分けプログラムが起動されるようにしておけば、メールの内容/サブジェクトによって動作を変えることができる。具体的には、~/.forward に
と書いておくことで、command が自動的に実行される (必ず "" で囲まなければいけない)。メール振り分けプログラムとしては、procmail コマンドが使われることが多い。
なお、~/.forward のパーミッションは 644 か 600 にしておくこと。664 (group writable) だと、~/.forward を解釈する sendmail が「セキュリティが甘い」と判断して、エラーとなる環境もある。
マウスをクリックせずにウィンドウをアクティブにするには
を
Style "*" MouseFocus(あるいはStyle "*" SloppyFocus)
にすればよい。
行入力支援ライブラリ readline の設定を行う。bash・gdb・bc・ftp など、行入力機能に readline を利用しているコマンドの CUI インタフェースについて、このファイルで設定を行うことができる。
設定を行うには、主に
という変数の設定を羅列する。例えば
とすれば emacs に似たキーバインドが設定される。一方、
とすることで vi に似たキーバインドが設定される。
●主な変数
editing-mode
編集モード設定。emacs か vi を設定する。デフォルトは emacs。
emacs とすると emacs に似たキーバインドになり、vi にすると vi に似たキーバインドになる。
completion-query-items
TAB を押下した際、補完候補が少ない場合は補完候補一覧を表示するが、補完候補が多すぎる場合は
% ls /usr/bin/ (TAB を押下)
Display all 417 possibilities? (y or n)
などと全ての選択候補を表示するかどうかをユーザに問い合わせる。completion-query-items は、「補完候補が何個以上ある場合に問い合わせを行うか」を設定する。デフォルトは 100。
expand-tilde
単語の先頭にあるチルダ「~」をホームディレクトリに展開するかどうかを設定する。展開するなら on、展開しないなら off を設定する。デフォルトは off。on の場合は
% ls ~/ (ここで TAB を押下すると)
% ls /home/68user/ (と展開される)
という挙動になる。
●コマンドごとの設定
~/.inputrc の内容は、readline を利用するコマンド全てに影響する。もしコマンドごとに異なる設定を行いたい場合は、$if〜$endif を使うとよい。
$if Bash
# パス（PATH）の編集
"\C-xp": "PATH=${PATH}\e\C-e\C-a\ef\C-f"
# 引用符で囲まれた単語を入力するための準備 -- 先頭と末尾の二重引用符
# を挿入して、先頭の引用符の直後に移動
"\C-x\"": "\"\"\C-b"
# バックスラッシュを挿入
# （シーケンスやマクロにおいて、バックスラッシュ・エスケープをテストする）
"\C-x\\": "\\"
# カレントな単語、または、1つ前の単語を引用符で囲む
"\C-xq": "\eb\"\ef\""
# バインドされていない行再表示コマンドにバインディングを追加
"\C-xr": redraw-current-line
# カレント行において変数を編集
"\M-\C-v": "\C-a\C-k$\C-y\M-\C-e\C-a\C-y="
$endif
# FTP 用
$if Ftp
"\C-xg": "get \M-?"
"\C-xt": "put \M-?"
"\M-.": yank-last-arg
$endif
~/.netrc ftp 用アカウント情報ファイル
ftp コマンドで ftp://ftp.jp.FreeBSD.org/ に anonymous ログインするには、
% ftp ftp.jp.FreeBSD.org
Name: anonymous
Password: (パスワード=メールアドレス入力)
と認証を行わなければいけない。さらに自分好みの設定にするには (当ページ管理人の場合)、
ftp> binary (バイナリモード)
200 Type set to I.
ftp> hash (1024 バイト転送するごとにマークを表示)
Hash mark printing on (1024 bytes/hash mark).
ftp> prompt (mget でいちいち取得するかどうかを問い合わせない)
Interactive mode off.
とタイプする必要がある。これでは非常に面倒である。
それを自動化するのが ~/.netrc というファイルである。
machine ftp.jp.freebsd.org
login anonymous
password 68user@X68000.startshop.co.jp
と書いておけば、
としただけで自動的にログインが行われる。ftp.jp.NetBSD.og にも同様のことが
したかったら、
machine ftp.jp.netbsd.org
login anonymous
password 68user@X68000.startshop.co.jp
を追加すればよい。
このようにいちいち対象 FTP サーバごとに記述するのが面倒ならば、
default login anonymous password 68user@X68000.startshop.co.jp
と書いておけば、エントリがない場合自動的にこの記述が使われる。ただし、default エントリが現れると ~/.netrc の読み込みがそこで止まってしまうので、必ず default エントリはファイルの最後に書く。
さらに ~/.netrc に
macdef init
binary
hash
prompt
(ここに必ず空行が必要)
と、init というマクロを追加すると、ログイン後に init マクロが自動的に実行される。
なお、~/.netrc は他人が読めないように
としておくこと。
うまく動かない場合は ftp に -d オプションを付けて挙動を観察するとよいだろう。
~/.nofinger finger をかけられても情報を表示しない
ホームディレクトリに ~/.nofinger というファイルが存在すると、そのユーザに関する情報が finger コマンドで表示されなくなる。~/.nofinger というファイルが
存在すればよい (中身はなくてもよい) ので、
とすればよい。ただし ~/.nofinger に対応しているのは GNU の finger だけ(?)である。
sh 実行時に自動的に読まれるファイル。また、bash 使用時には、~/.bash_profile がなかった場合だけ、このファイルが読まれる。
~/.rhosts rcp・rsh・rlogin 用のユーザ認証ファイル
このファイルには「信頼できるホスト名とユーザ名」を書いておく。
今ログインしているホストを foo.bar.com、そこでのユーザ名は user1 としよう。さらに、これとは別にアカウントを持っているホストを hoge.fuga.com、そこでのユーザ名は user2 としよう。
foo.bar.com の ~/.rhosts に
と書いておく。すると hoge.fuga.com から user2 が foo.bar.com に対して rcp・rsh を実行できるようになる。また、rlogin を使ってパスワード入力なしでリモートログインできるようになる。
それとは逆に、hoge.fuga.com の ~/.rhosts に
と書いておくと、foo.bar.com にログインしているとき、hoge.fuga.com に対して、rcp・rsh・ノーパスワードでの rlogin を使うことができる。
なお。~/.rhosts には
foo.bar.com user1
bar.baz.org user2
などと、複数のホスト名・ユーザ名を記述することができる。
rcp・rsh・rlogin を「r*」や「r系コマンド」と呼ぶ。セキュリティを重視するホストでは、rshd・rlogind を起動しないようにして、r系コマンドを使用できないようにしているところも多い。普通 rshd・rlogind は inetd 経由で実行されるので、r系コマンドを使えないようにするには、/etc/inetd.conf の rlogind・rshd の設定行をコメントアウトして
とすればよい。
~/.rhosts のパーミッションは 644 や 600 にしておくこと。他のユーザから更新できるようになっていると、セキュリティのためログインできないようになっている。
~/.tcshrc ログイン時に自動的に読まれる tcsh 用設定ファイル。
このファイルが無かった場合、~/.cshrc が読まれる。tcsh を使っている場合、初期設定を書くには、大別して3つのやり方がある。
1) 絶対に tcsh しか使わないなら、全てのシェル変数、環境変数、alias、complete などの設定を~/.tcshrc に書けばよい。
2) たまに csh を使うなら、csh・tcsh 共用の設定 (tcsh の内部コマンドである complete などを除いたもの) を ~/.cshrc に書いて、その中で
if ( ${?tcsh} ) then
endif
を書き、この if 文の中に tcsh 専用の設定を書けばよい。
3) あるいは、~/.cshrc に csh・tcsh 共用の設定を書き、~/.tcshrc に tcsh 専用の設定を書いて、~/.tcshrc の最後に
としてもよい。どの方法を取るかは好みの問題である。ちなみに当ページの管理人は、2番目と3番目を組み合わせている。
~/.Xdefaults X Window System のリソース設定を記述するファイル
X Window System のリソース設定とは、第二の環境変数のようなもので、X アプリケーションの設定を決めることができる。環境変数は子プロセスにだけ引き継がれるが、X のリソースは全ての X クライアントに反映される。
kterm の起動時に、ウィンドウが 90x45 の大きさになってほしいとしよう。この場合
とタイプすればよい。タイプがめんどくさいなら、
% alias kterm kterm -geometry 90x45
とすれば
だけで 90x45 のウィンドウが開くようになる。しかし、これではウィンドウマネージャのメニューから kterm を起動した場合は -geometry が認識されない。もちろんウィンドウマネージャの設定ファイルにも「kterm -geometry 90x45」と書けばいいのだが、ここで 91x50 に設定を変更したい場合、alias を設定したファイルと、ウィンドウマネージャの設定ファイルの両方を書き換えなければならず面倒である。
ここにリソース設定の存在意義がある。上記の例では ~/.Xdefaults に、
KTerm*VT100*geometry: 90x45
と書いておけば、その後起動される kterm のウィンドウサイズは 90x45 になるし、ウィンドウマネージャから実行しても同じ設定となる。
つまりリソースを設定すると、X アプリケーションの設定を一元管理できるわけである。
普通、「command」という名前の X アプリケーションは、「command.foo.bar」などというリソース名を参照する。例えば kterm は「KTerm.VT100.font」、emacsなら「emacs.Geometry」などを参照する。kterm は「KTerm...」、emacs は「emacs...」と、大文字小文字の違いに注意。一部のコマンドのリソース名は先頭文字が大文字だが、そうでないものもある。これは各アプリケーションの man を読んでチェックするしかないだろう (と思う)。
なお、行頭に「!」を付けると、その行はコメント行とみなされる。
~/.Xresources との違いは ~/.Xresources の項を参照してほしい。
~/.xinitrc X Window System 起動時に実行されるスクリプト
startx コマンドで X Window System を起動したときに自動的に実行されるスクリプト。X Window System をインストールしたばかりのときは、~/.xinitrc が存在しないので、代わりに /usr/X11R6/lib/X11/xinit/xinitrc が実行される。自分用のウィンドウ環境を構築したいときは
% cp /usr/X11R6/lib/X11/xinit/xinitrc ~/.xinitrc
% chmod +w ~/.xinitrc
として、~/.xinitrc を編集するとよい。
内容は ~/.xsession と全く同じで構わない。書くべき内容については ~/.xsession を参照。なお、~/.xinitrc は ~/.xsession と違って、
などと実行属性を付けておく必要はない。
このファイルの役割は ~/.Xdefaults と同じ。
~/.Xdefaults とは、xrdb でディスプレイに対してリソースを登録して「無い」場合に、XToolkit アプリケーションが起動時にサーバリソースデータベースとして読み込むファイルである。つまり、xrdb -query として、登録済リソースが表示されるような状況では、~/.Xdefaults は参照されない。
リソース設定を ~/.Xdefaults に書いておくと、各Xアプリケーションを実行したときに勝手に ~/.Xdefaults を読みにいってくれる。つまり、Xアプリケーションを実行すると最新の情報が反映されることになる。
一方、~/.Xresources は自動的に読み込まれることはないので、~/.xinitrc や ~/.xsession の最初の方に
xrdb -merge $HOME/.Xresources
と書いて、明示的にリソース設定を反映させる必要がある。このファイルを更新した場合も同じように xrdb でリソースを更新しなくてはならない。
と書くと、~/.Xdefaults に設定を書く方が便利そうに感じるが、Xクライアントを他のマシン上で実行している場合はローカルではなく、リモートの ~/.Xdefaults を読んでしまうという欠点がある。一方 ~/.Xresources に書くと、Xクライアントをローカルで実行しようとリモートで実行しようと、同じリソース設定が参照される。つまり、ディスプレイにプロパティとしてリソースを登録するのが xrdb コマンドなわけである。
リソースそのものの概念については ~/.Xdefaults を参照してほしい。
~/.xsession xdm からログインするときに実行されるスクリプト
X Window System をインストールしたばかりのときは、~/.xsession が存在しないので、代わりに /usr/X11R6/lib/X11/xdm/Xsession が実行される。自分用のウィンドウ環境を構築したいときは
% cp /usr/X11R6/lib/X11/xdm/Xsession ~/.xsession
% chmod +wx ~/.xsession
として、~/.xsession を編集するとよい。
例えばこんな感じ。
#!/bin/sh
xmodmap $HOME/.Xmodmap
xrdb -m $HOME/.Xresources
xset -b m 3 1
xset dpms 300 300 300000
kterm -T kterm1 -km euc -fn 8x16 -fk kanji16 -g 85x60+10+10 &
kterm -T kterm2 -km euc -fn 8x16 -fk kanji16 -g 73x52-10-10 &
kterm -T kterm3 -km euc -fn 8x16 -fk kanji16 -g 90x60+1290+10 &
twm
X の起動時に自動的に起動してほしいプログラムや各種設定を書いて、最後にウィンドウマネージャを実行するのが一般的だが、最後の部分を
twm &
kterm -T kterm3 -km euc -fn 8x16 -fk kanji16 -g 90x60+1290+10
と逆にするのを好む人もいる。
前者 (ウィンドウマネージャを最後に書く) は、ウィンドウマネージャを終了すると X も終了してしまう。後者は、ウィンドウマネージャを終了しても X は終了せず、最後に実行した kterm を終了すると X が終了する。いろいろなウィンドウマネージャを試してみたいときは、後者の書き方が便利である。
各行の最後の & の有無に注意。xmodmap や xrdb は設定を終えるとプログラム自体は終了してしまうので、最後に & を付ける必要はない (バックグラウンドで動かす必要はないということ。まぁ別にバックグラウンドで動かしても構わないんだけど)。しかし kterm は X アプリケーションであり、kterm 自体が終了しない限り次のプロセスは実行されないので、& を付けてバックグラウンドプロセスとして動かさなければならない。しかし、最後の行を
と & を付けてしまうと、afterstep をバックグラウンドで起動してしまい、~/.xsession の実行が終了してしまう。そのため、ログインして何もしないうちにログアウトしてしまう (その場合の修正方法は後述)。
また、~/.xsession は
として、必ず実行属性を付けておく必要がある。
ちなみに、最後の行を
でなく、
と書くと、~/.xsession を実行する /bin/sh のプロセスがなくなり (そのプロセスは afterstep を実行するから)、プロセス数を1つ減らすことができる。
もし ~/.xsession に実行権限を付け忘れたり、ウィンドウマネージャを起動する行に & を付け忘れると、ログインしてもすぐにログアウトしてしまい、~/.xsession を修正することもできなくなる。そういうときは、xdm のログイン画面でパスワードを入力するとき、最後のリターンキーを押さずに、F1 キーや Ctrl-Return を押すと ~/.xsession が無視され、xterm が1つだけ実行される (システム標準の設定)。そこで ~/.xsession を修正するとよい。
~/.xsession の中でのエラー、ウィンドウマネージャの出力するエラーなどは、~/.xsession-errors に書き込まれる。