ソースコード・リテラシーのススメ

第3回 ドキュメントをどう使うか?

この記事を読むのに必要な時間:およそ 4 分

各種ドキュメントの使い方

昨年秋にPlamo-4.21をリリースして以来,Plamo Linux以外の仕事に忙殺されていてメンテナンスをサボっていましたが,最近になってようやくPlamoの作業に多少時間を使えるようになりました。現在は,近日中のメンテナンスリリースに向けて,滞っていた各種更新作業に追われています。そのような作業の現場で,今までに紹介してきたドキュメントをどのように活用しているかを紹介してみます。

コマンドのオプション確認

/etc/passwdファイルには,登録されているユーザのログイン名やホームディレクトリ,使用するシェルなどの情報が記録されています。インストール直後の初期状態で,どのようなシェルやホームディレクトリが登録されているかを調べたくなりました。

ご存知のように,/etc/passwdファイルは1行が1ユーザに対応し,各行は“:”(コロン)で区切られた7つの欄から構成されています。

/etc/passwdファイルの例

 root:x:0:0::/root:/bin/bash
 bin:x:1:1:bin:/bin:
 daemon:x:2:2:daemon:/sbin:
 ...

ホームディレクトリの情報は6つめの欄,シェルの位置は7つめの欄に記載されているので,まずこのファイルから7つめの欄を取り出す方法を考えます。

Perlならば各行をsplit(/:/)で分割,awkならばフィールドセパレータ FS=’:’の指定で何とかなりそうですが,スクリプトを書くのも面倒なので,より簡単なUNIXのcutコマンドを使おうと考えました。cutコマンドは各欄の区切りをオプションで指定できたはずなので,⁠欄区切りを指定するオプションは-sだったかな?」とcutコマンドを使ってみました。

 % cut -s':' -f7 /etc/passwd 
 cut: オプションが違います -- :
 詳しくは `cut --help' を実行して下さい.

おっと,⁠オプションが違う」と怒られてしまいました。では,指示されているように cut --help を実行してみます。

 % cut --help
 使用法: cut [オプション]... [ファイル]...
 ファイルの各行から選択した部分だけを切り出して, 標準出力に表示します.
 
 長いオプションに必須の引数は短いオプションにも必須です.
   -b, --bytes=LIST        LIST に指定したバイト位置の文字を出力
   -c, --characters=LIST   LIST に指定した文字位置だけを出力
   -d, --delimiter=DELIM   フィールドの区切り文字を TAB の代わりに DELIM に
   -f, --fields=LIST       LIST に指定したフィールドだけを出力; -s オプション
                           が指定されなければ, 区切り文字を含む行も表示
 ....

これを見ると各欄(フィールド)の区切り文字はデフォルトではTAB変更するためには-dオプションだということがわかります。そこで先のコマンドの-sを-dに代えて実行してみます。

 % cut -d':' -f7 /etc/passwd
 /bin/bash
 
 /bin/sync
 /sbin/shutdown
 /sbin/halt
 ....

今度はうまくいったようです。こうして取り出したログインシェルをsortで並べかえて,使われているコマンドの頻度を調べたり,パイプ経由で xargs ls -lに流しこんで,想定しているコマンドが存在するか,パーミッション等は大丈夫かといった点を確認しました。

新しいパッケージの作成

昨年の秋にPlamo-4.21を公開してから,あっと言う間に10ヵ月近くの月日が流れてしまいました。この間に収録しているソフトウェアの多くがバージョンアップされています。これらバージョンアップにあわせてパッケージを更新していくのがディストリビュータの主な仕事です。

たいていのソフトウェアでは2.10や0.8.6のようにピリオドやハイフンで区切られた2桁,あるいは3桁の数字(バージョン番号)でバージョンを管理しています。これらの数字は左から,メジャー番号,マイナー番号,リリース番号などと呼ばれ,以前のバージョンからの変更点の多寡によってどの数字を更新するかが判断されます。

Linuxカーネルでは2.6.21.5のような4桁のバージョン番号を使っています。この場合,4桁目はパッチ番号と呼ばれます。また,3桁目の数字をリリース番号ではなくビルド番号として管理しているプロジェクトもあります。

どの程度の変更でバージョン番号のどの部分を更新するかは開発者に任されているため,バージョン番号の付け方はソフトウェアプロジェクトごとに異なっているのが現実ではありますが,大まかな合意としては以下のようなルールが存在するでしょう。

メジャー番号の更新
以前のバージョンと互換性が取れなくなるほどの大きな更新が加えられた場合
マイナー番号の更新
新しい機能等は追加されたものの,以前のバージョンとの互換性は保たれている場合
リリース番号の更新
機能的な追加や変更はほとんどなく,プログラムのバグ修正程度の場合

このようなルールを知っておけば,バージョン番号のどの部分が更新されたかによって,パッケージを更新する際の対応を変えることができます。たとえば,リリース番号の更新の場合はビルド用スクリプトのバージョン番号を変える程度で対応できるでしょうし,マイナー番号の更新の場合は今までになかった機能が追加されていないかを調べた方がいいでしょう。またメジャー番号が更新された場合は,0からビルドスクリプトを作り直すつもりで調べ直す必要があるでしょう。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたのが,いつの間にかミイラ取りがミイラになってOSSを仕事にするようになってしまいました。最近はスペシャリスト養成を目的とした専門職大学院で教壇に立ったりもしています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html