FreeBSDセットアップ「つまみぐい」その0 覚えておかないとシャレにならない基本操作 # 前後する説明が多いので、一度通して読んでみることを推奨 # コマンドリファレンスについては、http://x68000.q-e-d.net/~68user/をはじめ # 親切で丁寧な解説が他にいくらでもあるので、ここでは扱わない。 # 大まかな説明としても、http://www.wakayama-u.ac.jp/~tokoi/lecture/shori1/ # などこのドキュメントよりわかりやすいページがあるのでそちらも参照。 起動方法 電源投入直後に、 Hit [Enter] to boot immediately, or any other key for command prompt. という指示が出るが、ここでエンターを押せばよい。ただし、デフォルトでは 10秒待てば勝手に起動する。 # 自動起動までの時間は、/boot/loader.confのautoboot_delayという項目で # 好きに変更できる。 エンター以外のキー（スペースが一般的らしい）を押せばブートオプションを 自分で設定できる。ここでbootとだけタイプしてエンターを押せば、通常の 起動と同じになる。 boot -s と-sオプションをつければ、シングルユーザーモードが立ち上がる。 これはWindowsでいうSafeModeに近いもので、トラブルで通常のモード（こちらは マルチユーザーモードという）が立ち上がらない場合に使う。 # 単に自動で立ち上がる機能の数が違うだけなので、シングルユーザーモードで # 立ち上げたあとに必要なソフトウェアを自分で立ち上げれば、 # 手動でマルチユーザーモードに移行できる（リブートしたほうが楽だが）。 また、スペースやエンターの入力は、BIOSから入出力をもらった直後の、 BIOS drive A うんたら drive B かんたら という画面が出たあたりから有効になっているので、先に押しておいても構わない。 終了方法 http://www.jp.freebsd.org/QandA/HTML/464.html 電源の切り方 rootもしくはoperatorグループのユーザーで > shutdown -h now とやる（電源断は手動：最近のハードならacpi(4)に対応しているので、 -hオプションに代えて-pオプションを使えば自動で電源まで切れる）。 これが不可能な場合は、可能ならシングルユーザーモードに落として、 ディスク書き込みを行う # > shutdown now などとshutdownをオプションなしで実行すると # シングルユーザーモードに落ちる。 # nowも省略すると、デフォルトでは60秒待ってから同じ処理を行う。 可能性があるプロセスで止められるものはすべて止めてからディスクの処理を したいのだが、そんな余裕があるなら強制終了なんぞしない、というケースが多い。 ディスクへのデータ書き込みは、 > sync というコマンド。これを3回くらい実行してからCtrl+Alt+Delで強制リブートする。 # 2回目のsyncがシェルに制御を返してきた時点で # 1回目のsyncが完了したことが確認できるため、 # 3回目をやっても「念のため」以上の意味はないはずだが、 # 世の中「念」はけっこう大切なので筆者は3回にしている。 強制リブートもできない場合は電源ボタン長押しやリセットボタンで、 ハードウェアの仕様などでそれすら不可能な場合は電源を直接落とす。 # syncも実行できなければあとは祈るしかないらしいが、 # shutdownできないがsyncはできるなんてケースはかなりレア。 # なお、> shutdown -h nowにはsyncと同等の処理が最初から仕込まれている。 # 短縮形で> haltとしても> shutdown -h nowと同じ意味。 コマンドの終了 # フォアグラウンドとバックグラウンドについては後述 # ジョブのサスペンドなどについても後述 フォアグラウンドで動いているプロセスであれば、Ctrl+Cで止まる。たとえば > ping 127.0.0.1 としたあとにCtrl+Cを押せば、pingが止まるはず。 このほか、キーボードからの基本的な操作（sttyコマンド）として Ctrl-U(kill)：カーソルのある行を削除 Ctrl-H(erase)：カーソルの前の文字を削除 Ctrl-D(eof)：入力を終了（標準入力からEOFを送る） Ctrl-C(intr)：フォアグラウンドのプログラムを終了 Ctrl-Z(swtch)：フォアグラウンドのプログラムを一時停止（サスペンド） Ctrl-\(quit)：フォアグラウンドのプログラムをコアダンプつきで強制終了 Ctrl-S(stop)：スクリーンへの出力を一時停止 Ctrl-Q(start)：スクリーンへの出力を再開する（stopしていた間の分もまとめて出力） Alt+F1～F8：仮想コンソールの切り替え などがあるが、シェルの種類や設定によって一部操作が違う（eraseがCtrl+Xとか）。 # 実体は/bin/sttyだがあまり意識する必要はない。 デーモンの終了 # プロセスやPIDについての詳細はオマケの親プロセスと子プロセスを参照 デーモンをはじめとしてバックグラウンドで動いているプロセスは > ps -auxw # 実行中のプロセスを一覧表示。-uと-wのオプションは省いてもよい。 として終了したいデーモンのPID（プロセスID）を調べ、 # 長くなるので> ps -ax | more や> ps -ax | grep デーモン名の一部 # などとした方がよいかも。 > kill プロセスID もしくは > killall デーモンを呼び出したコマンド名 # 例：> killall inetd Xの終了 Xを終了したい場合は、最初に起動したアプリ（ウィンドウマネージャや 仮想コンソールであることがほとんどだろう）を終了すれば、勝手に コンソールに戻ってくれる。固まっている場合はCtrl+Alt+BackSpaceで強制終了。 コマンドと入出力 http://x68000.q-e-d.net/~68user/unix/pickup?%A5%EA%A5%C0%A5%A4%A5%EC%A5%AF%A5%C8 http://x68000.q-e-d.net/~68user/unix/pickup?%A5%B5%A5%D6%A5%B7%A5%A7%A5%EB http://www.fluidlab.naoe.t.u-tokyo.ac.jp/~minnie/unix/shell.html # まず、標準入力とか標準出力という用語についてだが、とりあえず、頭に # 「標準」がついた名前の入出力は、今操作しているコンソール（もっと # ぶっちゃけていえば、キーボードとシェルを表示している画面）のことだと # 考えておいて差し支えない（多分）。リダイレクトとパイプの項目も参照。 オプションやら引数やら戻り値やら 引数というのはプログラムに伝える指示のことで、たとえば > ee /etc/rc.conf のように、コマンドの後ろにスペースをはさんで示してやる。 # 上記の例では、eeに/etc/rc.confというファイルを開きなさいと指示している。 オプションはたとえば、 > ls -l のように、コマンドの後ろにスペースをはさんで、-から始まる文字列を追加する。 # 上記の例では、lsコマンドに-lオプション（詳細に表示させる）を追加している。 > cvsup -L /var/cvs.log のように、引数を必要とするオプションもある # 上記の例では、cvsupコマンドに-Lオプション（ログをとる）を追加して、 # -Lオプションの引数（ログファイルの場所）に/var/cvs.logを指定している また、> ls -a -F などというコマンドは、> ls -aF といった具合に省略して 書くことが可能。 戻り値というのはプログラムからの報告のことで、正常に処理が終了した場合には 0が返ってくる。1以上の戻り値は何らかのエラーがあったことを報告するが、 戻り値1の場合は、何かを判定して、その結果が偽であったことを示すことがある。 2以上の戻り値は、そのプログラムに固有のエラーを示すことが多い。 # 普段は気にする必要がないが、makeに失敗したときなどにreturn 1 という # 表示を目にすることはあるだろう。 たとえば > test -f /tmp/myfile として/tmp/myfileというファイルが存在するかどうか調べた場合、 ファイルが存在すれば0、存在しなければ1、何かの理由でtestコマンド自体が 実行できなければ2以上の値が返ってくる（はず）。 # 直前に実行したコマンドの戻り値は、> echo $? とすればシェルで表示できる。 # $?の意味についてはその8で触れる。 リダイレクトとパイプ > コマンド1 > ファイル1 で、コマンド1の出力先をファイル1に変更できる。たとえば > ls -l > filelist.log などとすれば、ls -lの結果（標準出力に表示されるはずの内容）を、 filelist.logというファイルを新規作成して書き込む。 # すでにファイルが存在した場合、削除してから新規作成される # > コマンド1 >> ファイル1 とすれば、最終行に追加してくれる > コマンド1 < ファイル1 で、ファイル1の内容をコマンド1に入力できる。たとえば > grep error < /var/mylog.log とすれば、/var/mylog.logの内容をgrepが受け取って、引数で指定した文字列である errorを含む行をピックアップしてくれる。 # このように入出力先を変えることをリダイレクトという。 > コマンド1 | コマンド2 で、コマンド1の出力内容をそのままコマンド2に入力できる。たとえば > ls -l | more などとすれば、、ls -lの結果（標準出力に表示されるはずの内容）を丸ごと moreコマンドに入力してくれる。 # このように、あるコマンドの出力を別のコマンドの入力として # そのまま渡すことをパイプという。 サブシェル 現在のシェルから子プロセスのシェルに外注を出すことができる。 # プロセスについては後述するが、同種のシェルをもう1つ立ち上げて # そこでコマンドを実行させるのだと思っておけばだいたい問題ない。 やり方は簡単で > (コマンド) と括弧にくくってやるだけ。数式を書くときの括弧と似たような使い方で、たとえば > (ls -l | more) > lslog.txt のようにコマンドをグループ化することもできる。 これとは別に、現在のシェルとは違うシェルを呼ぶことも普通にできる。 たとえばtcshを使っているときに > sh とするとshが起動してそちらに制御が移る。 # shをexitするとtcshに戻る。 リダイレクトとパイプ（もう少し詳しく） # ファイルディスクリプタについては、シェルによって文法が違うので # 注意が必要。ここでは/bin/shを使っていると仮定する。 リダイレクト先として/dev/nullという仮想デバイスが選択でき、 ここに出力した情報は表示も保存もされずに消えてしまう。 # つまり、出力を捨てることができる。 また、出力には標準出力と標準エラー出力の2種類があり、使い分けることが可能。 標準入力（stdin）は0番、標準出力（stdout）は1番、標準エラー出力（stderr）は2番と 番号がついている。 # この番号をファイルディスクリプタ番号という。Unixではほとんどのデバイスを # ファイルとみなしており、入出力先もファイルとして扱っている（のだと思う、多分）。 # 0番から2番までは上記の通り予約されているので、実際にファイルが使用するのは # 3番以降になる（ユーザーが意識する必要はほとんどない）。 > ls > ls.log とした場合、暗黙に > ls 1>ls.log としたと解釈（lsを実行して標準出力をls.logにリダイレクト）、 > grep "hoge" < myfile ならば、暗黙に > grep "hoge" 0< myfile としたと解釈（myfileを標準入力にリダイレクトしてgrep "hoge" を実行）されている。 > make 1>make.log 2>make-error.log とすれば標準出力と標準エラー出力を別々にリダイレクトできるし、 > make 2>make-error.log として標準エラー出力だけリダイレクトすることも可能。 ファイルディスクリプタの入出力先は>&を使って制御できるので、 > make 1>make.log 2>&1 とすれば「1の出力先はmake.log、2の出力先は1と同じ（この場合make.log）」 と解釈されて結局両方make.logにリダイレクトされる。 # 前から順に解釈されてゆくので、> make 2>&1 1>make.log と書くと、 # 「2の出力先は1と同じ（この場合コンソールの画面）、1の出力先はmake.log」 # という意味になる。 cshやtcshの場合、設定によっても事情が異なるが、たとえば、 file 2>&1 でなく >& file 2>&1 | command でなく |& command file1 2> file2 でなく (command > file1) >& file2 などが用いられる。 バックグラウンドとフォアグラウンド 通常、フォアグラウンド（Windowsでいえばアクティブという用語が近いか）で 動いているのはシェルであるが、何かコマンドを実行するとそのコマンドが シェルに取って代わってフォアグラウンドになり、処理が終了した時点で シェルに制御を返す。 たとえば、 > fstab というコマンドを実行すると、コマンドの実行が終わるまではシェルへの入力が できなくなる（実行時間に差はあるが、他のコマンドでももちろん同じ）。 しかし、 > コマンド & とすると、バックグラウンドでコマンドを実行する。たとえば > fsck & としておけば、fsckコマンドの実行中にもシェルの操作が可能 # 標準出力に流れるメッセージを、 # > fsck >> ~/fstab.log & なり> fsck >> /dev/null & なりと # リダイレクトしておかないと邪魔になるが バックグラウンドで実行中のコマンドやサスペンド中のコマンドは > jobs で一覧表示でき、> fg job番号 でフォアグラウンドで再開、 > bg job番号 でバックグラウンドで再開、> kill %job番号で終了できる。 # たとえば> kill %2 で（プロセス番号2ではなく）ジョブ番号2を終了する。 # 別に> ps コマンドでPIDを調べてkillしても問題はないが。 これを利用すると、フォアグラウンドで実行しているコマンドをいったん Ctrl+Zでサスペンドして、あらためてバックグラウンドで再開することも可能。 シェルの終了とプロセスの終了 シェルから実行したコマンドはシェル自体を親プロセス（オマケを参照）とするため、 シェルを終了すると（バックグラウンドで実行していたプロセスも含めて）シェルから 起動して実行中だった全プロセスが終了する。これを避けるにはnohupコマンドを使い、 > nohup コマンド & などとしてやればよい。nohupで動いているプロセスでも、SIGTERM（ようするに普通の killコマンド：意味はやはりオマケを参照）で止めることができる。 コマンドの結合 > コマンド1 ; コマンド2 とすると、コマンド1の後にコマンド2を続けて実行する。たとえば > cat file1 file2 >> file3 ; mv file1 file4 とすると、file1とfile2の内容を連結し、file3の最終行に書き込んだ後、 file1をfile4に変名する。 連続実行を明示的に示す場合は > {コマンド1 ; コマンド2} とする。ここで > (コマンド1 ; コマンド2) としてもコマンドの実行結果は同じだが、後者は別プロセスを立ち上げて コマンド1と2を実行するので、この後に実行されるコマンドへの影響が変わる。 # ()の中で環境変数を変更しても、元のシェルに戻ると無効になるなど さらに、AND演算子&&を使って > コマンド1 && コマンド2 とすると、コマンド1が成功した（返り値0を返した）場合のみコマンド2が実行される。 反対に、OR演算子||を使って > コマンド1 || コマンド2 とすると、コマンド1が失敗した（返り値が1以上の）場合のみコマンド2が実行される。 コンピュータに読ませるテキストファイル シェルスクリプト # 詳しくはその8で触れる。 シェルに実行して欲しい命令を書いておくテキストファイルで、拡張子は.sh。 最初の行に、どのシェルに実行させるのかを#! /bin/sh などと書いておく。 コンソールからコマンドで命令をするよりも、長くて複雑な指示が出せる。 実行時に> シェルスクリプト 引数 という形で引数も渡せる # たとえば> /usr/local/etc/rc.d/apache.sh stop とか 設定ファイル 名前の最後がrcもしくはconfになっているか、名前が.で始まっている場合がほとんど。 # .cshrcとか.xinitrcのように、合わせ技になっているものもある 書式はソフトウェアによって違うので、manコマンドを使ったり設定サンプルを 見たりして参考にする（googleを使うのが一番早いという話もあるが・・・） エスケープ文字（エスケープシーケンス）とクォーテーション ソフトウェアにとって特殊な意味を持つ文字。たとえばPerlの正規表現なら、 \という文字が特別な意味を持っており、\nで改行、\sでスペースを表す。 \という文字そのものを表現したい場合は\\とする。 この他改行や空白なども特別な意味を持つことが多い。たとえば~/.cshrcに alias makeauto make;make install などと書くと、シェルが~/.cshrcを読んだときに、makeのエイリアスとして makeautoを設定した後、make install をその場で実行してしまう。 これを防ぐためには、 alias makeauto 'make;make install' と、クォーテーションからクォーテーションまでが一続きであることを 明示的に示してやればよい。 # というか、とくに必要がなくても、普段からクォーテーションを # 使う習慣にしておいた方が、トラブルが少なくなるかもしれない。 なお、シングルクォーテーション「'」と、ダブルクォーテーション「"」と 逆クォート「`」は使い方が異なるが、詳しくはその9で触れる。 # 逆クォートは「コマンドの実行結果（出力）」を表す。 環境変数 ユーザーの好みや環境によって変わる情報を、変数として与えるもの。たとえば ホームディレクトリの場所とか、デフォルトで使うエディタとか、コンソール表示の 文字コードとか。これらが可変情報（つまり変数）になっていることで、設定が 大幅に簡単になる。 例として> man プログラム名 とやった場合、manコマンドは ページャ（表示ソフトウェア）を起動するが、そのときどのソフトウェアを 起動するかを~/.cshrc内のsetenv PAGER という行で（いちいちmanコマンドに 手を入れなくても）指定できる。 また、ホームディレクトリを環境変数に登録しておけば、~/をホームディレクトリの 意味で使うことができる。 # デフォルトでは、rootなら/root/、一般ユーザーなら/usr/home/ユーザー名が~/。 # たとえばuser1というユーザーなら、/usr/home/user1/と~/が同じ意味になっている エイリアス（別名）も登録しておくと便利で、たとえば~/.cshrcで alias ls 'ls -la | more' としておけば、> ls だけで> ls -la | more としたのと同じことになる # ただし、元の> ls が使えなくなるので、それでは困るという場合は # alias lm ls -la | more などと違う名前にしておけばよい シェルの設定の場合、> source ~/.cshrc としないと、再ログインするまで設定が 有効にならない。 # ~/.cshrcで環境変数を設定するのはcsh系のシェルだけ。 上記の環境変数とは別にシェル変数というものもあり、こちらはシェルの内部だけで 参照される。環境変数のほうは、シェルが起動した子プロセスからも参照される。 # 環境変数でHOGE=mogeとした場合、シェルから起動したmydaemonにもHOGE=mogeが # 通用するが、HOGE=mogeがシェル変数だった場合、シェルから起動した # mydaemonには通用せずHOGEはHOGEとしてそのまま解釈されるということ。 コメントアウト 行の途中（もしくは行頭）に#があると、たいていのソフトウェアはそこから 次の改行までを読み飛ばす。このコンピュータには読まれない部分をコメントといい、 読み飛ばして欲しい部分に#をつけることをコメントアウト、逆に#を削除することを コメントを外す（もしくはアンコメントアウト）という。 # 普通は#を行頭につけて行ごとコメントアウトする 今は必要ないが後で使いたい設定を一時的に無効にする場合や、デフォルトの 設定を記録しておきつつ独自の設定をする場合に便利。 /*から*/まで（複数行を一括指定可）をコメントとみなすソフトウェアや、 （#の代わりに）//などを使ってコメントを表現するソフトウェアもある。#や//など、 始点と終点を明示できない方法でのコメントアウトは、複数行を一括指定できない。 # 複数行にわたってコメントアウトしたければ、コメントアウトしたいすべての # 行に#をつける。 パス 絶対パス /ディレクトリからツリーをたどった場合の位置。たとえば /usr/local/sbin/のように、/から書き始める。 相対パス 今いるディレクトリ（カレントディレクトリ）からたどった場合の位置。たとえば カレントディレクトリが/usr/home/user1/だったとして、./dir1/file1なら、 /usr/home/user1/dir1/file1を指す（カレントディレクトリを示す./は普通省略して、 dir1/file1と書く） ../は親ディレクトリを指し、カレントディレクトリが/usr/home/user1/だったとして、 ../user2/file1なら/usr/home/user2/file1を指し、../../sbin/なら/usr/sbin/を指す。 パスを通す ~/.cshrc中のset path の項目で指定したディレクトリにある実行ファイルは、 ディレクトリの指定なしで、ファイル名のみで実行できる。たとえば ~/.cshrcにset path = (/bin/ /sbin/$HOME/bin)と書いてあれば > /bin/cat や> /sbin/fsck や > ~/bin/mycommand の代わりに > cat や> fsck や > mycommand とだけ指定しても/bin/catなどが実行される # インストール直後の場合、先に> rehash しておく必要がある # ~/.cshrcでパスを通すのはcsh系のシェルだけ パーミッション パーミッションについては、ちょっとぐぐればいくらでも解説があるのでそちらを参照。 自分しか使わないファイルは0600、それで動かない場合は0700にしておけばたいてい 間違いない。他人にも見せたい場合は0644などに設定するが、よく考えてからにする。 # オマケの実行権限とrootユーザーの項目も参照すると、もう少しわかるかもしれない /tmpなど「みんなが書き込めた方がよいがだれでも消せると困る」ディレクトリは 1777などに設定する。最初の1はsticky bitと呼ばれ、所有者（とroot）しか 削除できなくなるフラグ。 # 最初のバイトでsetuidとsetgid（イジるな危険）の設定もできる。 空ファイルを作る > touche 作るファイル名 とすると空ファイルが作成される。toucheはもともとファイルのタイムスタンプを 現在時刻（もしくは-tオプションで設定した時刻）に変更するためのコマンドだが、 なぜかファイルの新規作成にも利用される。 > ee 作るファイル名 としてから何もしないでexitしてもよい。 # いずれも1行1文字のファイルになる オンラインヘルプなどの参照 http://www.jp.freebsd.org/man-jp/ http://x68000.q-e-d.net/~68user/unix/pickup?man > man コマンド名 というコマンドでオンラインヘルプ（man）を表示できる。デフォルトでは英語表示だが、 portsからjapanese/manをインストールすると日本語オンラインヘルプ（jman）も 利用できる（日本語情報が欲しい場合はウェブブラウザを使った方が早いので、筆者は インストールしていない）。 たとえば「ls(1)」のようにコマンド名の後ろに括弧と数字を書くことがあるが、これは manの章番号を表している。この例では「manの第1章に説明があるlsというコマンド」 という意味になる。章分けはディストリビューションごとに多少異なっており、 FreeBSDでは 1 General Commands (tools and utilities) 2 System Calls (system calls and error numbers) 3 Library Functions (the C libraries) 4 Kernel Interfaces (devices and device drivers) 5 File Formats 6 Games 7 Miscellaneous Information 8 System Manager's Manual (system maintenance procedures and commands) 9 Kernel Developer's Manual (system kernel interfaces) となっている。適当に訳すと 1 一般的コマンド（ツールとユーティリティ） 2 システムコール（システムコールとエラー番号） 3 ライブラリ関数（C言語ライブラリ） 4 カーネルインターフェイス（デバイスとデバイスドライバ） 5 ファイルフォーマット 6 ゲーム 7 その他 8 システム管理者用マニュアル（システム保守の手順とコマンド） 9 カーネル開発者用マニュアル（システムカーネルインターフェイス） となる。 たとえば「intro」のように複数の章に同じタイトルのマニュアルがある場合、 > man 3 intro などとして何章のマニュアルか指定する。省略すると章番号がもっとも若い項目だけが 表示される（> man intro だとintro(1)だけ出てくる）。-aオプションをつけると すべての章を検索してヒットした項目を順に表示する（> man -a intro だと、 intro(1)の後にintro(2)、その後にintro(3)のように続く）。マニュアルファイルの 保存場所だけを表示する（マニュアルの内容は表示しない）-wオプションと併用すると、 ヒットする項目がどの章にあるか調べられる（たとえば> man -aw intro とすると 「/usr/share/man/man1/intro.1.gz」などマニュアルの保存先がリストアップされる）。 マニュアルは普通/usr/share/man/以下にあり、/usr/share/man/man1/が「1章」の ディレクトリである（intro.1.gzはintro(1)の項目の本体）。 オマケ 用語 UNIX OSの名前（本来は形容詞だが、名詞として使われる例も一般的）。 現在ではPOSIXという規格があって、これを満たせば「POSIX互換」ということになる。 # 派生がいろいろあるが、7thEdition以降はsystemVとXenix（SCO-UNIXに改称）が有名。 # 商標の絡みがあるので、POSIXの規格を満たしても即UNIXを名乗れるわけではない。 # 開発者はMULTICSというOSに関わったベル研のKen ThompsonとDennis Ritchieが最初で、 # もともとは名称もUNICSだったらしい。 UNIX略歴 1967-1969年、MULTICSというOSに関わったベル研のKen Thompson とDennis Ritchie が PDP-7というハード（DEC社のミニコン）上にアセンブラでOSを書く。開発開始当初の 名前はUNICSで、すぐにUNIXと改称された。後のUNIX Time-Sharing System （単にUNIXといえば、狭義にはこれを指す）と区別するためにUNIX PDP-7と 呼ぶことが多い。 1971年、PDP-11というハードに実装される（UNIX Time-Sharing System 1stEdition） 1973年、カーネルなど大部分をC言語で書き直す（4thEdition）。 1974-1975年、BSDとPWB（Programmer Work Banech）が本家UNIXから派生し始める。 1976年、6thEdition公開、この辺からBSDとPWBが本格的に分離 1979-1980年、UNIX 32V（7thEditionの後継）、BSD、PWBの3系統が存在。 1979年、XENIX（8086用UNIX）公開（後のSCO UNIX）。 1980年、UNIX 32Vのコードも取り入れ3BSD公開、引き続き4.0BSDも公開。 1982年、UNIX 32VとPWBが合流してUNIX SystemIIIに。4.1BSDからSunOSが派生。 1983年、UNIX SystemIIIの後継としてUNIX SystemV公開。 1985年、BSD系とSystemV（PWB）系の成果を本家UNIX 32Vに還流させて8thEdition公開。 以後BSD系の成果を吸収しつつ本家UNIX Time-Sharing Systemは10thEditionまで続く。 1988年、UNIX SystemVはBSD系の成果を徐々に取り入れてゆき、Release4でSunOSと合流。 以後SolarisとUNIXWareに分離。 1990年、4.3BSD Reno公開。 1991年、4.3BSD Renoからライセンス上問題となる部分を削除した4.3BSD Net/2公開 （最初期のLinuxがリリースされたのも1991年らしい） 1994年、4.3BSD Renoを改めて書き直した4.4BSD Lite公開。 BSD Berkeley Software Distributionの略で、UNIXからの派生。6thEditionくらいの ときに分かれはじめて、コードの書き直しとか裁判なんかを経て独立した。 1BSDとか2BSDとか、バージョン番号が頭についている。 4BSDのマイナーバージョン 4.3BSD Reno にはライセンス上問題となる部分が残っており、それを除去したのが 4.3BSD Net/2、しかし裁判の結果まだ問題があることがわかり、改めてRenoの 書き直しを行い、最終的に（すくなくとも米国内での）ライセンス問題を すべてクリアしたのは4.4BSD Lite らしい。 http://www.oreilly.co.jp/BOOK/osp/OpenSource_Web_Version/chapter03/chapter03.html SunOS 4.1BSDからの派生。後にsystemVと融合してSolarisになる。 386BSD 4.3BSD Net/2からの派生、というかi386への移植。 FreeBSD 386BSDの更新が滞ったために、もともとUnofficial 386BSD Patchkit を 作っていた人たちが新たに始めたらしい。最初（FreeBSD1.0）は 386BSDをベースにしていたが、ライセンス問題から4.4BSD Lite ベースで 書き直された（FreeBSD2.0）。現在、386BSDのコードはほとんど残っていないらしい。 NetBSDやOpenBSDからイイトコドリをしつつ、実用性重視のOSに仕上げている。 FreeBSDのメジャーバージョン 1.0が1993年、2.0が1994年、3.0が1998年、4.0が2000年、5.0が2003年（のはず）。 2004年に6.0の開発が始まったが、5.2から5.3（安定版）と6.0（開発版）が 分かれることになる。 FreeBSDの開発ブランチ -CURRENTが最新、-STABLEがそこそこ安定、-RELEASEがかなり安定したリリース。 正確には、CURRENTブランチとSTABLEブランチの2つの開発ブランチがあり、 STABLEブランチのなかで一般公開用に特に安定させたものを-RELEASEとしている、 のだと思う（多分）。4.10以降はErrataブランチ（緊急でないものも含めて、 適用しても安定性を損なわない修正を追加していく）というのもできた模様。 MFC（Merged From -CURRENT） -CURRENTでの変更を（-RELEASEや-STABLEに）取り入れる（Mergeする）こと。 NetBSD バージョン0.8まで4.3BSD Net/2ベースだったが、バージョン1.0で 4.4BSD Lite ベースに変更された。非常に多くのプラットフォームに移植されており、 対応プラットフォーム表には世界に何台実機が残っているのかわからないような プラットフォームも並んでいる。先進的な機能を多く開発しており、NetBSDで 開発された機能が他のOSに移植されることも多い（FreeBSDやOpenBSDだけでなく、 WindowsやMacにも）。 OpenBSD 4BSDからの派生（公式サイトには4.4BSDベースと書いてある）だが、初期の 中心メンバーはNetBSDの開発者が多かったらしい。セキュリティを重視しており、 デフォルト状態でも非常にセキュリティが堅く、セキュリティ機能が他のOSに 移植されることも多い。アメリカの暗号輸出規制を回避するために本拠地を カナダに置く念の入れよう。 MacOSX NextStepというOSが元になっており、Machというマイクロカーネルの上に FreeBSDベースのサーバ（サブシステム）を乗せたもの（Darwinという）が 中心になっている。UnixアプリケーションはBSDサーバが提供するAPIの上で 動いているが、ネイティブアプリやClassic環境用アプリは別のサーバ（Quarts、 Cocoa、Aquaなどがオブジェクト指向的に重なっている）を利用している（多分）。 BSD/OS BSDi社（Berkeley Software Design の略らしい）が開発していた商用OSで、 紆余曲折の末2003年に販売終了。4.4BSD-Lite2ベース。BSD/OSとセットになる形で FreeBSDの商標も数社の間を転々としたのだが、経過が複雑である（間違ってるかも）。 どうやら、もともとFreeBSDを配布していたWalnut Creek CDROMをBSDiが買収、 BSDiのソフトウェア資産をWind River Systemsが買収、残ったBSDiの組織 （ハードウェア中心）はiXsystemsに改称、Wind River SystemsはFreeBSDの 資産をFreeBSD Mallに売却、iXsystemsがFreeBSD Mallを買収、ということのようだ。 行ったり来たりしすぎてわけがわからない。 # ちなみに、iXsystemsはPC-BSD Softwareも買収したらしい。 BSD系OS 自らBSDを名乗っているものはよいとして、どこからどこまでをBSD系として くくるのかはいろいろと意見がある模様。 FreeBSDの派生OS これもどこまでを派生と見るか次第だが、DragonFly BSD、FreeSBIE、PC-BSD あたりが有名。 BIOS 人間が手動で起動（電源ボタンを押す）する唯一のプログラム。ハードウェアの 基本的な管理をしているが、カーネルを起動させた後は大部分をカーネルに引き継ぐ。 カーネル OSの中心部分。BIOSからブートローダーというプログラムを経由して起動される。 起動や終了を含めたソフトウェアの制御を任されているほか、実際にハードウェアを 動かしていろいろな処理をしているのもここ（カーネルサービスという）。ちなみに、 カーネル再構築というのは、カーネルのソースコード自体を書き直すわけではなく、 コンパイルオプションを変更してカーネルをコンパイルし直すことを指す。 # ソースまでいじるのはカーネルハックという プロテクトモードとか特権モードとか システムのメモリ空間全体にアクセスできるのがリアルモード（ペンティアム互換 プロセッサではリング0という）、自分に割り当てられたメモリ空間にしか アクセスできないのがプロテクトモード（同じくリング3という）。リアルモード・ カーネルモード・特権モード、およびプロテクトモード・アプリケーションモード・ ユーザーモードがそれぞれほぼ同義なのだが、微妙にニュアンスが違ってややこしい。 モノリシックカーネルとマイクロカーネル サービスを「できる限り」アプリケーションモードで動かすのがマイクロカーネル、 そうでない（カーネルモードで動かす）のがモノリシックカーネルということに なっているが、結局程度の問題になる。カーネルとドライバのリンクがスタティックか ダイナミックかということとは無関係（のはず）。 プリエンプティブマルチタスクとノンプリエンプティブマルチタスク カーネルがアプリケーションにハードウェア資源を使わせる際に行う管理方法の分類。 ノンプリエンプティブマルチタスクでは、たとえば「CPU使ってもいいけど0.1秒 経ったら返してね」といった感じでハードウェア資源を貸し出す（このため 協調的マルチタスクとも呼ばれる）。このとき、アプリケーションが無限ループに 入るなどしてCPUを返してくれなくなると、OSごとフリーズする（どんな状況でも 資源は返すように設計するのが正しいが、すべてのアプリケーションが正しい処理を 行っているわけではない）。プリエンプティブマルチタスクの場合、 返さない奴からはムリヤリ取り上げるのでクラッシュするのはアプリケーションだけで 済む。FreeBSDにもpreemptionが導入されているが、バージョン5.0の時点では 「much more work is left to be done」な状態だった（6.xで本格導入されるはず）。 ドライバ ソフトウェアとハードウェアの間を取り持つプログラム。普通はカーネル直属の 部下（カーネルモジュール）もしくはカーネルの一部になる。 アプリケーション カーネルからの呼び出しで起動するプログラム。ハードウェアには触れることが できないので、ユーザーからの入力を受けるのにも、作業結果をディスクに 保存するのにも、画面に結果を表示するのにも、カーネルに処理を依頼している。 カーネルとユーザーの間を取り持つ役割があり、シェルがその代表例。 # 間にカーネルが入らないとユーザーの入力を受けられないのに変だ、 # と思えるかもしれないが、詳しくは人間の命令とコンピュータ動作のモデルを参照 ミドルウェア それ自身はカーネルに呼び出されて動いているが、自前のドライバで直接 ハードウェアとやり取りをしたり、他のアプリケーションに独自のAPIを 提供したりする。カーネルとアプリケーションの中間的存在。 API アプリケーション利用できるカーネルなどの機能をセットにしたもの。 # 筆者はあまりよくわかっていない シェル ハードウェアの制御をしているのはカーネルだが、たとえばカレントディレクトリの ファイル一覧を見たい場合に「ディスクのこれこれの部分にアクセスして 書いてある内容をしかじかの出力装置に云々」とやっていると日が暮れてしまう。 そこで、この作業を代わりにやってくれるのがシェル。 # 上記の例の場合、シェルに「ls」と命令すればよい CUIシェル（総合的な機能を持ったインタープリタ）と、GUIシェル（マウスの クリックやドラッグなどをカーネルへの命令に翻訳してくれるソフトウェア）の 2つがあるが、CUIシェルの方を単にシェルと呼ぶことが多い。 # CUIシェルではコマンドラインを使うのが普通。 # インタープリタの項目も参照 CUI Character User Interface の略。文字だけを使って入出力を行う方法。 GUI Graphical User Interface の略。アイコンやマウスも使って入出力を行う方法。 CLI Command-line Interface の略。コマンドラインを中心にしたインターフェイスで、 海外ではCUIのことをCLIと呼ぶらしい（厳密な区別はないようだ）。 コマンドライン コマンドを使ってコンピュータを操作するための仕組み。複数行の入力は できないのが普通で、改行を入力するとコマンド実行の命令と解釈される。 インターフェイス 原義は境界面とか接触面という意味だが、コンピュータ用語としては 入出力（というか情報のやり取り）を行う仕組みや、そのための装置を指す。 シェルコマンド シェルに実行させる命令（lsとかcpとか）。シェルが自前で実行する内部コマンドと、 外部のプログラムに外注を出す外部コマンドがあるが、ユーザーが意識する必要は あまりない。 モジュールとかライブラリとか 他のプログラムからの外注を受けることを専門にしているプログラム。 # 呼び出しの方法によって名前が変わる デーモン（daemon） バックグラウンドで自律的に動くプログラムで、名前の最後にdがつくことが多い。 # 「OOしたらXXしておいてね」という指示を受け付けるものを指すのが普通で、 # ブラウザとかコンパイラあたりがバックグラウンドで動いていても、 # ほとんどの場合デーモンとは呼ばない 擬人化してデーモン君と呼ぶ。 サーバ 他のプログラムに呼ばれて作業をするプログラム。デーモンの代表例。 # たとえばftpサーバなら、他のプログラムに呼ばれたときにファイルを渡すのが仕事 クライアント 他のプログラムを呼んで作業をしてもらうためのプログラム。 # たとえばhttpクライアントは、httpサーバにお願いしてファイルを渡してもらう P2P peer to peer の略で、サーバとクライアントの区別がはっきりしないプログラムや、 サーバとクライアントが兼用になっているプログラムを指す。ntpdやdnsdが代表例。 # たとえばntpdは、他のプログラムに呼ばれたときに時刻を教えてあげるのが # 仕事である一方、他のntpサーバにお願いして時刻を教えてもらうこともある 端末（ターミナル） コンピュータと繋いで入出力をする装置。普通はモニタとキーボードがついている。 # 昔はコンピュータ本体と端末がはっきり分かれていた コンソール コンピュータ本体と直接やりとりするための入出力装置。要はコンピュータ本体に 直接繋がっているモニタとキーボードのこと。コンソールからXを立ち上げると、 Xが入出力を占拠してしまうため、仮想コンソール（エミュレータ）が用意される。 # 実際には、Xを立ち上げなくても出力は仮想コンソール上で行われている。 # 多くの環境では、Alt+F1〜F8で仮想コンソールの切り替えができる。 パソコン（PC） パーソナル（個人用）コンピュータの略で。狭義にはIBMのPC/AT互換機を指す （Personal Computer/Advanced Technologyの略らしい）。 # ちなみに、PC/ATの後継がPS/2（Personal System/2の略）で、 # PC/ATが採用していたMS-DOSの後継がOS/2（Operating System/2の略）。 # PC/ATやPS/2のI/O規格は実機よりもはるかに長生きし、 # 今でもATキーボードとかPS/2マウスなどとして（細々ながら）生き残っている。 マイコン マイクロコンピュータの略とも、オフコンに対してマイコンピュータの意味で 呼んだとも。パソコンとの明確な区別はないが、8ビット以下でシングルユーザーの マシン全般をこう呼ぶことが多い。OSにはUNIX由来（PDP-11からの移植らしい）の CP/M（Control Program for Microcomputersの略らしい）などを採用していた。 メインフレーム 汎用機とも。大規模で高性能な汎用コンピュータ（さまざまな用途に対応）。 I/OインターフェイスがIBMのシステム/360互換であることが多い。 スパコン スーパーコンピュータの略。大規模で高性能な専用コンピュータ（数値計算なら 数値計算、画像処理なら画像処理に特化した性能を持つ）。 ミニコン （メインフレームと比べて）小さなコンピュータのこと。実際にはPCと メインフレームの中間サイズになる。サーバ機能を主目的とするものは ワークステーションもしくは汎用サーバ、オフィス用に特化したものは オフィスコンピュータ（オフコン）などと呼ばれる。 # ワークステーションという呼称もパソコンとの境界が曖昧。 ICMP Echo Request 通称Ping。 ICMP Echo Reply 通称Pong（とは呼あまり呼ばないが）。Pingを返す、という言い方の方が普通。 VT-100 DEC社の端末の名前。ものすごく有名な商品らしいが、筆者は見たことがない。 X Window System（もしくは単にX） Xという名前の、ソフトウェアを四角い枠（つまり窓）の中で動かす仕組み。 GUIシェルのハード寄りなインターフェイスを受け持っている（多分）。 # X11R6はXのバージョン11リリース6 XFree86とXorg Xをi386に移植したもの。後になってXFree86からXorgが分かれた。 VT-100のエミュレータを含んでいる アセンブル言語（アセンブラ言語） コンピュータへの命令を直接書く言語。アセンブラという翻訳機で翻訳する。 # しゃがんでいる人間に「立て」という命令をする場合でたとえると、 # 「右大腿四頭筋と左大腿四頭筋を収縮」（これだけだと間違いなく転ぶが・・・） # といった感じか。きめ細かい指示を出せるので強力だが命令が面倒。 高級言語 コンピュータにやって欲しいことを、自然言語に近い形で書く言語。人間が書くのは ソースコードと呼ばれる計画書（というか設計図）だけで、実際にコンピュータへの 命令を書くのはコンパイラという装置。 # 上記の例でいえば、 # 「右足と左足を伸ばす」 # といった感じか（どこそこの筋肉を云々の部分はコンパイラが書いてくれる）。 C言語が代表例。 ツールキットとかランタイムとか よく使う命令をライブラリやモジュールにして、さらにひとまとめにしたもの。 # 上記の例でいえば、 # 「ツールキット内の立てライブラリを実行」と命令するだけでよい # というか、実際に書くのは「立て」の一言だけ。 インタープリタ言語（インタプリタ言語） # 詳しくはその9で触れる ソースコードを事前にコンパイルせず、実行するときにコンパイルする高級言語。 コンピュータに命令を出す装置はコンパイラではなくインタープリタ、 ユーザーが書いた計画書はソースコードではなくスクリプトと呼ぶことが多い。 # スクリプトではなく、コマンドラインからのコマンドを受け付けるものもある。 awk、perl、ruby、PHPなどが有名だが、シェルスクリプトもこの仲間。 # というか、シェル自体がインタープリタの一種なので当然といえば当然 スクリプトには、最初の行に、#! /usr/bin/perl などと、誰に仕事を頼むのか 書いておかないと動かない（オプションも指定できる）。 # この行のことをインタープリタ行という。スクリプトを（たとえば # パイプやリダイレクトを使って）直接インタープリタに渡す場合は必要ない。 インタープリタ（インタプリタ/インタープリッタ） # これも詳しくはその9で触れる スクリプトを実行するスクリプトインタープリタか、コマンド（1行なのが 普通）を実行するコマンドインタープリタか、どちらかの機能を持っていれば、 一応インタープリタの一種ということになるが、単にインタープリタといえば スクリプトインタープリタを指すのが普通。ただし、ほとんどのCUIシェルは 両方の機能を兼ね備えているし、本来はスクリプトインタープリタ専用であっても シェルからの入力に応じてコマンドライン用のループを自動作成してくれるものが多く、 コマンドインタープリタと似たような感覚で使える。 # シェルから別のコマンドインタープリタを使う場合、シェルだけでは能力不足になる # 処理を外部のインタープリタに代行してもらうといったイメージになる。 # あるシェルから別のシェルに外注を出すことももちろん可能。 シェルスクリプト シェルにいろいろと仕事を頼むためのスクリプト。どんな環境でも動くようにするには、 POSIX標準の/bin/shを使う必要がある。 人間の命令とコンピュータ動作のモデル # シェルになにかコマンドを実行させる場合 命令の伝達順序に着目すると、だいたい下記のような流れになる。 アプリケーション（シェル）がユーザーとカーネルの間を取り持ち、実際の作業は カーネルが（ハードウェアを使って）行っているということがわかる。 人間：シェルに命令 シェル：カーネルに作業依頼 カーネル：ハードウェアに指示 ハードウェア：作業実行 カーネル：シェルに作業終了を通知 シェル：作業結果を画面に表示 人間：作業結果を目で見る ただし、シェルはユーザーからの命令を直接受け取るわけではないので、 実際の動作順序に着目すると、以下のようになるだろう # コメントアウトしてあるのは、上記の例で意識されていない部分 人間：キーボードにタイプする #ハードウェア（キーボード）：コンピュータ本体に信号を送る #カーネル：入力があったことをシェルに通知 シェル：作業内容を決定しカーネルに依頼 カーネル：CPUやメモリに命令 ハードウェア（CPUやメモリ）：作業実行 カーネル：シェルに作業終了を通知 シェル：結果表示をカーネルに依頼 #カーネル：モニタに結果表示を指示 #ハードウェア（モニタ）：信号どおりに表示する 人間：作業結果を目で見る 実行権限とrootユーザー Unixはもともと複数の人が使うことを前提にしていたので、カーネルは「相手を選んで」 命令を聞くようになっている。たとえば他の人が実行中のプログラムについて 「あのプログラム止めてくれよ」と命令しても、「アンタの命令は聞けないな」と 命令を蹴ってしまう（もし止めてしまったら、実行したユーザーが大迷惑する）。 また、ファイルについても、所有者でない人が「このファイル書き換えて」と命令しても、 （所有者が「書き換えたい奴がいたら書き換えちゃっていいよ」といっていない限り） 書き換えることはできない。 # これがファイルのパーミッションで、書き込み以外に読み出しや実行も制限できる。 ただし、rootユーザーの命令に限っては、（当のrootユーザーが過去に出した命令と 矛盾していたり、そもそも実行が不可能だったりしない限り）カーネルはあらゆる命令を 実行する。 # これは非常に危険なので、rootでの作業は最小限にとどめたい。 また、suというコマンドを使えば、一時的に他のユーザーになったことにして コマンドを実行できる。 # ユーザー管理についてはその3を参照。 親プロセスと子プロセス http://www.jp.freebsd.org/cgi/mroff.cgi?subdir=man&lc=1&cmd=&man=kill&dir=jpman-5.2.0%2Fman§=0 まずプロセスという言葉だが、現在動いているプログラムのことをプロセスといい、 普通プロセスIDという番号で表す。シェルからpsコマンドを使うと一覧表示できる。 # 正確な言い方ではないが、ここではこの理解で問題ないはず。 また、psコマンドを使わなくても、バックグラウンドで動くことを前提とした プログラムの多くは、自分のプロセスIDを書き込んでおくための、拡張子が .pidのファイルを（デーモンの設定ファイルで指定した場所に）作成する。 # 普通は/var/run/以下だが、たとえばapacheならhttpd.confのPidFileという行で # 作成場所を変更できる ユーザーがプロセスに命令する（シグナルを送る）場合、プロセスIDを指定する 必要があり、たとえばntpdを停止したい場合に、ntpdのプロセスIDを（psコマンドか pidファイルを使って）調べて、 > kill ntpdのプロセスID と指定してやるのはこのためである。 アプリケーションが他のアプリケーションの機能を使いたい場合、自分では他の プログラムを起動できないので、カーネルに頼んで起動してもらうことになるが、 自分が呼び出したプロセスについてはある程度責任を持って管理をすることがある。 # 呼び出した方を親プロセス、呼び出された方を子プロセスという たとえばpostfixを動かしているときに > ps -auxw | grep postfix とすると、rootが実行しているプロセス1つとpostfixが実行しているプロセスが いくつか表示されるはずだが、この場合、root権限で動いているのが親プロセスで postfixの権限で動いているのが子プロセスになる。 ここでrootユーザーが親プロセスに終了のシグナルを送った場合、親プロセスは、 自分が起動した子プロセスを（カーネルにお願いして）終了してから自分自身を 終了する（root以外は自分が起動したプロセスしか終了できないが、この場合、 自分が起動したのだから、当然終了の権限も持っているはず）。 # シグナルの項目も参照 root権限が必要な作業（syslogへの書き込みとか）をするプロセスを、root以外の 人が触れるプロセスと隔離しておくことで、プロセスが誰かに乗っ取られた場合の 被害拡大を防ぐ効果がある。上記の例でいえば、外部のユーザーと接触があるのは postfixの権限で動いているの子プロセスだけなので、たとえ乗っ取られても すぐにシステムの中心が破壊されることはない（破壊するだけの権限がない） # Unix系のOSでは、rootユーザー（とrootユーザーが「信用していいよ」と # 宣言したユーザー）以外は、基本的に信用しない（大きな権限を与えない）。 プロセスの親子関係はツリー状に広がっており、大元のプロセスはinitと呼ばれる。 initはSIGKILL（次の項で説明）さえ無視できる特殊なプロセスで、もし何かの理由で 親プロセスだけが終了してしまった場合、孤児になったプロセスはinitプロセスが 引き受けて里親になる。また親プロセスが子プロセスを終了するとき、親プロセスは 子プロセスが終了したのを見届けるまでwaitして、プロセスを管理するシステムに 「たしかに終了しました」と報告しなければならす、終了しているのに終了報告が なされていないプロセスをゾンビプロセスと呼ぶ。普通は一瞬しかそのような 状態にならないが、親プロセスが変な終了の仕方をすると、ゾンビプロセスが 長時間残ることがある（単にゾンビプロセスと言った場合、この長時間タイプを 指していることがほとんど）。 シグナルとKillコマンド http://www.jp.freebsd.org/cgi/mroff.cgi?subdir=man&lc=1&cmd=&man=kill&dir=jpman-5.2.0%2Fman§=0 シグナル（UNIXシグナルとも）というのはユーザーが直接プロセスに 命令する場合に使う信号で、シグナルナンバーという番号で表現する。 これは、POSIXの仕様で決まっており、たとえばシャットダウン画面に signal 15 などと出てくるアレなのだが、1番（SIGHUP）は端末のハングアップ、 15番（SIGTERM）は終了、30番（SIGUSR1）はユーザー定義1を プロセスに通知することになっている（下記参照） http://www.nurs.or.jp/~sug/soft/super/signal.htm#sec3 ただし、ユーザーが自分でプロセスに信号を送るのでは不便なので、 killなどのコマンドを使ってシェルにやらせるのが普通。 killコマンドは、デフォルトで15番（SIGTERM）をプロセスに送るが、 -1や-9といった具合にオプションを指定してやれば、それ以外の シグナルも送ってくれる。 また、上記のシグナルを受け取ったプロセスの実際の動作としては、 1番（SIGHUP）を受け取ったら子プロセスを全終了して再度起動、 15番（SIGTERM）を受け取ったら子プロセスを全終了して親プロセスも終了 といった動きをすることになるようだ。 よく利用されるシグナルは以下の通り # コマンド：意味：実際の動き > kill -1（> kill -s HUP）：hang up：再起動 > kill -2（> kill -s INT）：interrupt：プロセスの中断 > kill -3（> kill -s QUIT）：quit：プロセスの中断（コアダンプあり） > kill -9（> kill -KILL）：non-catchable, non-ignorable kill：強制終了 > kill -15（> kill -TERM）：software termination signal：終了 > kill -30（> kill -USR1）：User-defined signal 1：ユーザー定義1 > kill -31（> kill -USR2）：User-defined signal 2：ユーザー定義2 なお、BSD系のシステムでは29番がSIGINFO（ddの様子を見るときなどに使う）に 割り当てられているが、これはシステムによって異なるらしく、SystemVでは SIGPWR（電源障害により再起動）、Linuxの一部ではSIGLOST（電源消失） になっているらしい。 2番と3番はキーボードからの入力用。たとえばCtrl+Cを押した場合、 フォアグラウンドで動いているプロセスに2番のシグナルが送られる。また、 killコマンドがデフォルトで送るコマンドはSIGKILLではなくてSIGTERMだったりする。 この他に17（SIGSTOP：一時停止）と19（SIGCONT：再開）もたまに使う。 29番のSIGINFOはCtrl+T。 エディタ Unix系システムでもっとも基本的なエディタはedで、ラインエディタと呼ばれる 行ごとの編集を前提とした作りから、簡易なディスプレイでも使用できる。 常用している人はほとんどおらず、シェルでいうshのような立ち位置。どんな環境でも 同じ挙動を期待できること、grepやsedなどと共通する操作などから、スクリプトで 呼ばれることも多い。 edを改良したのがex、さらに複数行を表示しながら編集できるスクリーンエディタに 作り変えたのがviで、シングルユーザーモードでのテキスト編集に活躍するほか、 FreeBSDではvipwのようなシステム系コマンドに組み込まれている例もある。 操作の大筋はedから引き継いでおり、キーボードだけで使用できる。 マウスも使えるエディタとしてはEmacsが有名。もともとTECOというエディタの マクロ集だったらしく、Emacs LispというLISP方言を使ってゴリゴリと スクリプトで押せる。 CUIで使えるとっつきやすいエディタとしては、FreeBSDに標準で入っているeeや、 LinuxやMacで使われるnanoなどがある。GUIで使えるものは（Emacs以外）これといって 目立ったものがないが、しいていえばGnome系のgeditとKDI系のKEditあたりが有名か。 エディタではないが、catに標準入力を流してやると（ムリヤリ）テキスト編集に 使うことができ、これで用が足りてしまうこともけっこうある。 suとsudo suは別ユーザー（> su ユーザー名のように指定：省略すると> su rootだと解釈される） としてログインするためのコマンド。-lまたは-mオプションで、環境変数などを 捨てるまたは保持する選択ができる。rootの特権として、パスワードなしで 他のユーザーにsuできる。FreeBSDのsuではwheelグループに属するユーザー以外 rootにsuできない。 いったんログアウトしてから改めて（rootで）ログインするのと何が違うのかというと、 exitしたときに元のユーザーに戻れるのはもちろんそうなのだが、とくにsshで リモートログインするときなど、直接のrootログインを禁止してsuを使うと 少し安全になる。 sudoは別ユーザー（デフォルトはroot）としてコマンドを実行するためのコマンドで、 > sudo 任意のコマンド という書き方になる。/usr/local/etc/sudoersで管理ができ、実行したコマンドが /var/log/messagesや/var/log/syslogに記録される。デフォルトだとsudoした後 数分の間、再び同じユーザーにsudoするときはパスワードを求められない。 -sオプションはシェルの実行で、> sudo /bin/shなどとしても同様のことができる。 このときログにはshを実行したことしか記録されない。環境によってはsuと ほぼ同様に使えるが、/usr/local/etc/sudoersによる管理を受けるかどうかが一番の違い。 # BSD系のsuには前述のwheelグループによる管理があるので、セキュリティのために # sudoだけ入れてsuをインストールしない運用は比較的マイナー ユーザー指定は-uオプションで、> sudo -u ユーザー名のように行う。