ファイル - みる会図書館

1. UNIX MAGAZINE 2000年10月号

けつま 3 びっドトれています。ログを書き入れて言当求すると、 CVS は変更部分をすべて調べてリポジトリに反映させます。このコマンドでは、コマンドを実行したディレクトリ以下の変更がすべて反映されます。下層のディレクトリ中の一部だけをリポジトリに反映させたい場合は、目的の場所に移動してコマンドを実行してください。ファイルの追加 (cvs add) 作業スペースて新しくディレクトリやファイルを作ったときに、それをリポジトリに反映させたい場合は、、 cvs add " コマンドを使います。たとえば、新しく作ったコ ive ーⅲ fo " というファイルを登録したければ、 % cvs add live—info とします。するとこれに対して、 cvs add : scheduling file C1ive—info' for addition cvs add : use ' cvs commit' tO add this file permanently と出力され ( 誌面の都合 E 、で折り返しています ) 、ファイル」助日の準備か整ったことが示されます。このコマンドでは、、、次の cvs commit の際にファイルをリポジトリに追加する " という予定が言当求されるだけなので、実際に新しいファイルをリポジトリに追加するには cvs commit コマンドを実行しなけれはなりません。ファイルの削除 (cvs remove) リポジトリからファイルを削除するためのコマンドは CVS remove -- ( ーす - ・このコマンドを使うためには、ますイ乍業スペース上の目的のファイルを実際に削除する必要があります。次に、 % CVS remove live_info とすると、リポジトリからファイルを削除する準備がおこなわれます。 cvs add の場合と同様に、実際のファイル削除は次回の cvs commit 実行時におこなわれます。ファイル名の変更モジュール中のファイル名を変更したい場合はちょっと面倒です。いったん当求されたファイルの名前自体は変更できないので、 cvs remove と cvs add を組み合わせて使う必喫があります。 UNIX MAGAZINE 2000.10 必要な作業は、 1. 作業スペース上からもとのファイルを消去して cvs re- 2. 別の名前て伺し内容のファイルを用意して cvs add 3. 最後に cvs commit で両方の処理をリポジトリに反映させるの 3 段階です。たとえば live-info ファイルの名前を con- cert-info にしたけれは、 % mv live_info concert_info % CVS remove live_info % cvs add concert—info % ・ CVS commit のように実行します。しかし、このようにすると過去の変更履歴情幸ゞ失われてしまいます。師匠に訊いたところ、 CVS の仕組みを完全に理解していればリポジトリの内容を直接変更してファイル名を変更することもできるようですが、そうすると運用上の問題カ噺たに発生すると指摘されました。現在の CVS では、、一度登録したファイルは永遠に残しておく " と考えて、、ファイル名の変更 " という機能はないと思っていたほうがよいようです。リポジトリとの同期 (cvs update) よく使うコマンドの最後は、、 cvs update" です。これは、リポジトリの朋大をイ乍業スペースのモジュールに反映させる " コマンドです。 cvs update は、 1 人きりで 1 つの作業スペースから CVS を利用しているときはそれほど使いませんが、 1 人で使っているにせよ複数の人間て使っているにせよ、複数の竹璞スペースか存在する場合にはもっとも頻繁に使うコマンドになります。 CVS で cvs commit を実行する際には、たんに作業スペース中のファイルでリポジトリ中のファイルが上書きされるわけではありません。リポジトリのファイルと作業スペースのファイルの差分をとって、その部分だけを応央させているのです。複数の倚喋スペースか存在する場合には、リポジトリとイ′ド業スペースを同期させてからファイルに対して処理を加えて cvs commit で反映させるまでのあいだに、別の作業スペースからの変更が cvs commit されている可能生 101

2. UNIX MAGAZINE 2000年10月号

験はよくある。これと同しで、イ乍業の途中でちょっとしたことのために作ったメモやプログラムをしばらく経ってから見ると、そもそもなんのためにファイルにしたのかさえ分からないことがある。しかも、そんなファイルにかぎって名前の付け方がいい加減で、さらに混乱してしまうのである。このため、ディレクトリをリストしてファイル名を見ても、その内容を思い出すのは容易ではない。ファイル名はたんなるヒントにすぎず、そのヒントがまったく役立たないことも少なくない。事実、 memo. txt などのありふれた名前のファイルは、私のホーム・ディレクトリのいたるところに散在している。ファイルを作った目的が分からないもう 1 つの原因は、、、そのファイルを作った意図 " という情幸ゞ欠落してしまい、重要度がまったく判別できない点にある。たとえは、あるディレクトリにい TEX で書かれたドキュメントがあったとしよう。これなら、エデイタでファイルを開いて内容を石忍することはできる。ところが、よくよく考えて作ったつもりのドキュメントでも、あとで見ると、・誰に提出したのか・いつ作成したのか・誰か変更したのかといった作業の外的な条件を示す情報がなく、けっきょくなんのために作ったのかがさつばり分からないこともある。プログラムやい TEX のマクロなどを書いていると、その途中で補助的な作業をするために作った小さなシェル・スクリプトや Perl のプログラム、マクロやスタイルファイルなどがいくつも作りだされる。このようなものを作成するときは、コメントをきちんと書いたり、ファイルの情報を言当求しておくファイルを別に作ったりはしないのカ通である。このため、作業を終えてからある程度以上の時間が過ぎると、いったいなんのために作成したのかと思い悩むことになる。 ↑帯長を効率的に再利用するには、それがどのような目的で作られ、どう使われたのかがはっきり分かる情報も提連載 UNIX Communication Notes—O UNIX MAGAZINE 2000.10 供されなけれは、目的のファイルを探し出すことさえ難しい。ファイルは開かないと分からないさらに大きな原因は、アプリケーション固有のファイルか数多く登場してきたことである。単純なテキストファイルなら、 grep などでファイル内容の一部を検索すれはある程度の見当はつく。しかし、アプリケーション固有のデータは、いちいち適切なアプリケーションで開いてみなけ川ま内容の石忍ができない。このようなファイルか増えるにつれて、目的とするファイルの探索に時間がかかるようになってきた。 UNIX システムでは、ほとんどのファイルはもともとテキストファイルとして書かれ、それを適当なアプリケーションで変換して利用するのが普通である。したがって、 UNIX 環境でこのような間題に直面することはあまりない。ただし、 GIMP などの描画アプリケーションや idraw 、 Tgif といったドローツールで作成したファイルなどは、そのアプリケーションで開かないかぎり内容は分からない。 Windows 環境では、この傾向にさらに拍車がかかる。多くのアプリケーションが生成するデータファイルはバイナリ形式であり、たいていはそのアプリケーションが手許にないと内容を石忍できない。たとえば、 Microsoft Of- fice で作られたファイルは、 ( ビューアが用意されているものもあるか ) 作成したアプリケーションで開かないかぎり内容は分からない。デジタルカメラて撮景彡した画像や MP3 形式の音楽ファイルなど、マルチメディア系のデータについても、アプリケーションで市忍しないと内容力吩からないものか増えている。画像ファイルなら、サムネールによるカタログを作れば、ある程度は手間を減らせるかもしれない。しかし、商品のサンプル写真のように、一見同じようではあっても細部が異なる画像が数多くある場合には簡単には判別できないだろう。最終的には、作成したものと同しアプリケーションを用いてファイルの内容を石忍する以外にない。この竹業には、手間も時間もかかる。最悪のケースは、作成したアプリケーションがなくなってしまい、内容を見ようにも手だてがない場合である。 35

3. UNIX MAGAZINE 2000年10月号

連載 UNIX Communication Notes— 148 このように、利用するハードウェアやオペレーティング・システムの不頁か増えるたびに、管理しなけれはならないホーム・ディレクトリか増え、結果としてその下にあるファイルの数も増えていく。そして、こまめに手入れをしておかないと、「これはいったい何のためにとってあるのだろうか ? 」と首をひねるようなファイル、つまりはゴミと化したファイルか増え続けることになる。教訓 1 管理しなければならないファイルは増え続ける今回は、このように増え続けるファイルの管理方法を考えてみたい。ワーキングセットによる分類作業をおこなう過程で、どのような、、もの " が使われるかをみていくと、、、ワーキングセット (working set)" という考え方にたどりつく。たとえは、なんらかのプログラムを書く作業をみていこう。プログラム開発に最低限必要なのは、一殳には次のようなものである。・プログラムの仕様をまとめた言書・プログラムの開発に必要な技彿了資料作業に着手すると、プログラムのソースコードはもちろん、ソースコードのコンパイルを管理するための Make- file やシェル・プログラム、さらにコンパイル後のオプジェクト・コード、そして実行形式ファイルなどが作られる。完成間近になると、作成したプログラムのマニュアルページなども書くだろう。このような、 1 つの作業に必要な資料や、イ 1 璞によって生成されるさまざまなファイルをワーキングセットと総称する。そして、多くの人は、このワーキングセットを感覚的にグルーフイヒして管理している。私カワログラムを作成する場合は、その作業ディレクトリに開発中のプログラムを表す名前を付け、さらに、 : プログラムのテスト竟・マニュアノレ / 、一ジ : ソースコードとコンパイルイ乍業場戸斤 doc : 開発に必要な資料を保管するディレクトリ : コンパイルした結果をイ褓内するディレクトリ 34 test man . bin といったサプディレクトリを作る。そして、各種の作業ファイルをそれぞれの下に置いて整理している。一方、論文などを書くときは、新たなディレクトリを 1 っ作り、あとあと文章の内容などカ甘伹則できるような名前を付ける。たとえは、・に処理学会の角見記事を書くのなら、・ ipsj-article-200008 といったディレクトリ名にする。そして、そのディレクトリに I ÉX フォーマットの原稿を置き、さらに figures : 図表データ用 graphs : グラフ作成用などのサプディレクトリを作ってファイルを整理したりする。このように、ワーキングセットをし頁に置いてファイルを分類すると、上交的扱いやすい環竟か構築できる。川 2 作業しやすい王竟は、ワーキングセットを念頭に置いた情報整理から生まれるゴミと化すファイルおそらく、多くの人は無意識に作業に里するファイルをグルーフイヒし、サプディレクトリにまとめ、ワーキングセットとして管理しているはすである。それでは、ワーキングセットにもとづいてう嶽頁したディレクトリは、再利用を考えた場合に本当に便利なのだろうか。なんらかの作業をしているあいだ、我々はそれぞれのファイルの内容をほは正確に把握している。ー印判勺な竹喋ファイルを作った場合も、それが竹喋ファイルであることは記慮にとどめているはすだ。ところが、作業か完了し、そのディレクトリを使わなくなってしばらく経っと、それらのファイルをなんのために作ったのかと頭をかしげることが多くなる。ファイル名はヒントにしかならないその原因の 1 つは、かならすしもファイル名が内容の孑伹則に役立っとはかぎらないことにある。日常生活でも、電話で話している最中にとったメモをあとで読むと、なんのことだかさつばり分からないという経 UNIX MAGAZINE 2000.10

4. UNIX MAGAZINE 2000年10月号

連載 UNIX Communication Notes— 0 人間は気まぐれであるこれは、コンピュータ・システムではなく人間の間題である。イ乍業をするときのディレクトリの構成力法やファイル名の命名規則などについて、一貫したルールを決め、それを守り続けられるのなら上記の間題はかなり軽減される。しかし、現実には一度決めたルールを守りとおせる人は稀であろう。部署の移システムの変更といったタ様勺な要因によって、ルールを変えなければならないこともある。したがって、ある程度以にの年月かをしたあとで、かって作業に使っていたディレクトリを見ると、その時点でのルールとはかけ離れた分類をしていることも少なくなバックアップと保管この問題について言義していると、かならずバックアップを効果的におこなえばよいというアドバイスを受ける。私がホーム・ディレクトリの管理が大変だと嘆いていると、たいていは「使わなくなったファイルをまとめてバックアップして、それを保管しておけばいいんですよ。そうしたら、管理しなけれはならないファイルも減るし」と言われる。しかし、私はこのアドバイスにば通勺である。たしかに、情報のバックアップは必須の作業である。バックアップがなけれは、ディスクに障害が発生したときに、データを復旧することはできないからだ。したがって、バックアッフ作業そのものの必要性を否定するつもりはい増え続けるゴミ以にのようなことから、ワーキングセットにもとづく分類も、再利用や検索という視点からは万能とはいえない。 8 月上旬に、私の使っていたデスクトップ PC (Windows また、アプリケーションがなけ川ま内容の石忍ができない NT4.0 ) のディスクがクラッシュした。 : た学でのオフィスワークに使っていたシステムだったのだが、日頃の怠慢がたたって、ファイルもある。とくに、作成してから年月か登過した数カ月前のバックアップしかない状態になっていた。ひさびさファイルは、そのデータを扱うアプリケーションがなく、バックアップの重要性を痛感させられた・なったり、新たな工竟では使えなくなったりして、手のしかし、情報の保管方法としてバックアップを考える打ちょうがない状態になることもある。と、本当に使いやすいのだろうかと疑う気持ちが出てくこうして、ディスクのなかにはゴミか増え続けていく。る。しかも、ついつい「もしかしたら、このファイルは重要かバックアッフでは、原則として作成した時点でのディレもしれない・・」などと考えてしまい、内容の確認がでクトリ構成をそのまま保管する。なぜなら、バックアッフきないファイル、なんのために作ったのか分からないファの第 1 の目的はディスクトラブルに備えることであり、情イルも、そのままいすわり続けてしまうのである。報のを目的として作成することは少ないからだ。この孝蛆 0 3 : ファイルの再不堋を念頭に置いたファイル管理をため、情報を再利用しようと、作成したバックアップのなしなければ、ゴミとなるファイルは増え続ける。とくに、かから目的のデータを探し出す手間はディスク上にある場利用できなくなったアプリケーションのデータファイルは合よりも大きい。始末に負えないもちろん、バックアップの作成時にファイルを検索しこまでに挙げた問題を鮹夬するには、次のような技術やすいように整理し、必要なファイルを探すための労力をが必要である。軽減するように配慮しておけはよいのだが、多くの場合、バックアップはその点の環境をそのまま言当求するかたち・ホーム・ディレクトリで使用するディスク容量の増加 ( 単曽加 ) を抑える技術になっている。そのため、けっきよくは内容をいちいち・作成したファイルの内容を石忍する技術石信忍しながら探すといったことになってしまう。情報を再利用する場合に目的のファイルを効率よく探すバックアッフ。のもう 1 つの問題は、メディアである。ための技術アクセスしやすいものであ川まよいが、独自のドライプや再利用できないファイルを減らす技術プログラムが必要なものは、ディスク上のファイルを扱う 36 UNIX MAGAZINE 2000.10

5. UNIX MAGAZINE 2000年10月号

Daemons & Dragons る。 get と同様の構文で設定する。たとえば、回線速度はほかのインターフェイスごとのパラメータも、 Tar- 除き、コミュニティ名はかならす変更してはしい。インターネットに公開 ( または変更可能に ) する場合をミュニティ名は private")o ルータの設定や統言督直をて自動的に public" が設定される ( 言翹てり / 書込みのコタ・ソフトウェアでは、読取り専用コミュニティ名とし名、 @、ルータ自体の名前を指定する。はとんどのルート番号で、続けて SNMP の言荊てり専用のコミュニティるためのものだ。数字 ( 上の例では 1 ) はルータのポー name" は、出力やほかの設定でターゲットを識別すように設定ファイルに指定する。ット " と呼ばれ、、、 Target [name] : l:public@router ' のルータのインターフェイスは、 MRTG では、、ターゲ ( コロン ) で区切られたキーワードと値から構成され設定ファイルの各行は、、、 Refresh: 300 " のようにきる。 HTML の自動生成のすべてについて柔軟な指定がで設定ファイルでは、データの収集、グラフの生成、設定ファイル起動するたびにログ全体を書き直さなければならない。る。ただし、減衰型のデータ保存形式では、 MRTG をより、ログファイルの大きさは一定に近い状態に保たれにこのようなデータの削減を自動的におこなう。これにのデータしか含まれない。 MRTG は、実行されるたび粒度のデータが含まれるが、昨年のログには 1 日の粒度は 1 日のデータに集計される。先週のログには 5 分間の 15 分間のデータは 2 時間のデータに、 2 時間のデータの経過とともに、 5 分間のデータは 15 分間のデータに、データが重要ではなくなることを前提としている。時間減衰型のデータ保存形式は、前月に収集された詳細なそれ以降はファイルの大きさは制限される。字列 0 をもち、実際のデータに置き換えられる ) が、してから一定期間は増大する ( どの履歴フィールドも文ァイルが際限なく増え続けることはない。ログは、起動限に増えることを防ぐためのものである。事実、ログフ破棄される。この、、減衰型 " の保存形式は、ログが無制ではない。 MRTG では、一定期間か経過したデータは 84 、 MaxBytes[name] : 8000 " のように孑旨定する。この行では、チャート生成時のスケールを設定している。設定ファイルの構文の詳細は、 MRTG パッケージに含まれる HTML ファイルで説明されている。設定ファイルには膨大な情報を記述するため、一から作成する気にはならないだろう。さいわい、 MRTG には設定作業を支援するツールが含まれている。 PerI スクリプト cfgmaker は、 SNMP を使ってターゲットとなる機器に間合せをおこない、そのインターフェイスや状態、名前などの情報を取得する。それらを設定ファイルに書き込み、ファイルを標準出力に出力する。これで、 MRTG の設定の難しい部分は片づいた。ファイルを一から書くよりも、できあがったファイルを変更するはうがはるかに簡単である。 cfgmaker を使って設定ファイルを作成する際には、作業ディレクトリの指定を変更しなければならない。作業ディレクトリでは MRTG の変動する情報がすべて管理され、 MRTG が監視するインターフェイスごとに 1 組のファイルが置かれる。具体的には、さきほど述べた破棄されるデータを含むログファイル、 4 つのストリップ・チャートからなる 4 つの GIF ファイル、情報を閲覧するための HTML ファイルである。 . 。 ld というサフィックスが付いたファイルもあり、、これは旧いログファイルである。作業ディレクトリを指定する行は、、、 WorkDir: /opt /mrtg/share" のようになる。 MRTG の作業ディレクトリは、 Web サーバーから参照できる場所にしたはうがよい。これはいくっかの方法で実現できる。もっとも簡単なのは、 /opt/apache /share のように、 Web サーノヾーのディレクトリ・ツーに配置することだ。 Web サーバーの設定でディレクトリを組み込む方法もある。これは、 Apache なら Directory" ディレクテイプを利用する。最後に、データを 5 分おきにコピーするという方法がある。最初の方法では、 MRTG は Web サービスを提供するホストに配置される。しかし、パフォーマンスの間題でこれを避けたい場合もある。そのような場合は、 rcp や NFS などを利用し、ネットワークを介して Web サーバーが MRTG の最新の情報にアクセスできるようにしなければならない。 MRTG のページの処理を専門におこなう UNIX MAGAZINE 2000 ユ 0

6. UNIX MAGAZINE 2000年10月号

- けつま 3 びっド表 1 CVS のおもなコマンド内容コマンド CVS リポジトリを作成する init もとになるファイルを CVS に求する import 作業用ディレクトリにファイルを書き出す checkout ファイルに対する現在の変更を表示して、作業用ディレクトリを消去する release ファイルをリポジトリと照合して書き換える commit リポジトリに新しいファイル / ディレクトリ ( ェントリ ) を j 助日する add リポジトリ中のエントリを削除する remove 作業スペースをリポジトリに垬月させる update バージョン間の違いを表小する diff patch コマンド用の diff ファイルを作成する rdiff 各ファイルの状盟帯長を表示する stat us 各ファイルに対する履歴情報を表示する 10g リポジトリのアクセス言求を表示する history リポジトリの初期化 (cvs init) て便利です。 CVS の使用法についてはほかにも、コマンドラインからシステム・マニュアルを参照できますし、上最初にとりあげるのは、初期化コマンド (cvs init)" で己の Web ページ以外にも WWW 上にさまざまな解説がす。これは、最初に CVS リポジトリを作成するためのコあります。マンドです。この段階では CVS に登録するファイルやディレクトリを用意する必要はありませんが、リポジトリ CVS のコマンドを作成する場所を決めなければなりません。次に、 CVS のおもなコマンドについて紹介していきま完全に個人て利用する場合は、 CVS リポジトリを自分す。コマンドラインで、のディレクトリ内に置いてもよいかもしれません。しか % cvs ——help—commands し、別の計算機から使う可能生なども考えて、私は /usr/ と入力すると、コマンドー覧か画面に出力されます。その local ディレクトリのなかに cvsroot というディレクトリなかから、以下でとりあげるコマンドを含め、私のよく使を作って、このなかを CVS リポジトリとすることにしまっているものを表 1 にまとめました。私は CVS ではおもした。 root 権限で cvsroot ディレクトリを作り、所有者に文書ファイル ( テキストファイル、い TEX のソースファを yuzuko に変更しておきます。これで yuzuko の権限イル、 HTML 形式のファイルなど ) を管理しているので、でこのディレクトリ内にアクセスできるはすです。プログラム作成時によく使うコマンドとはすこし異なる選以下の作業は、一鍛ューサー (yuzuko) の権限でおこな択になっているかもしれません。いました。 CVS を使って複数のユーザーで共同作業をおこなう場合は、リポジトリ内にあるファイルへのアクセス最初に使うコマンド権が正しく設定されるよう、グループなどの設定に注意しまず、 CVS リポジトリと作業スペースの作成に使うコてください。マンドをまとめます。ここでは順に、次に、 CVS リポジトリのディレクトリを指定して、、 cvs init" コマンドを入力します。このとき、ディレクトリは・ CVS init 寸パスで指定する必要があります。私の場合は以下のよ・ CVS i mp ort うに実行しました。・ cvs checkout ・ CVS release % cvs —d /usr/local/cvsroot init これで cvsroot の下に CVSROOT というディレクトをとりあげます。リができあがり、そのなかにこの CVS リポジトリ全体の管理に使われるファイルが作られます。いつも同しリポジ 1 一 = ロ 98 UNIX MAGAZINE 2000 ユ 0

7. UNIX MAGAZINE 2000年10月号

, けつま 3 びっ図 2 cvs import のログ . んカ This is the first version for claudia. CVS : CVS : Enter Log ・ Lines beginning with CVS : CVS : ( CVS : ' are removed automatically トリを使うと思われる場合には、シェルの工羅竟変数に場所を登録しておくと自重加勺にその情報か読み込まれるようになるのてイ叫リです。以下のようにシェルの設定ファイルに追加しておきましよう。・ csh 、 tcsh の場合 setenv CVSROOT /usr/local/cvsroot ・ sh 、 b ” h の場合 CVSROOT=/usr/IocaI/cvsroot export CVSROOT モジュー ) レの登金泉 (cvs import) リポジトリが用意できたら、次は CVS の管理下に置くディレクトリやファイルを登録しなければなりません。リポジトリに登録されるディレクトリやファイル群をひとまとめにしたものをモジュールと呼びます。リポジトリにモジュールを求するコマンドは、、 cvs import" です。ます、登録したいファイルやディレクトリが含まれるディレクトリに移動して僻当求したいファイルをまだ作っていない場合は、空のディレクトリでもかまいません ) 、以・モジュール名 (claudia) cvs import" の次に並んでいる項目は順に % cvs import claudia yuzuko initial 下のように入力します。 UNIX MAGAZINE 2000.10 態です ) ェデイタを終了すると、そのディレクトリにあるを書き込んで ( 図 2 は 1 行目にすでにログを書き込んた漱定されているエデイタカ起動されます。ここで適当なログ面 ( 図 2 ) になります。このときは環境変数 ED 工 TOR に指 cvs import を実行すると、登剥のログを入力する画す。ように登録先のリポジトリの位置を指定することもできまです。オプションを指定すれは、上記の cvs init と同じリリースタグ ( 登宝剥寺の状態に付ける名前 ) (initial) ・べンダータグ ( 作成者名のことが多い ) (yuzuko) ファイルがモジュールとしてイ求され、 cvsroot ディレクトリの下に claudia ディレクトリが作成されます。この時点で、登録するファイルか置かれていたもとのディレクトリはいったん削除し ( 大事なデータなら、念のためバックアップをとっておきましよう ) 、そオ人降のファイルの変更は次に説明する、、 cvs checkout" を使って竹業スペースでのみおこなうようにするとよいでしよう。モジュールの取得 (cvs checkout) 上の 2 つのコマンドでリポジトリ ( サーバー側の準備か整ったので、次はイ乍業スペースを準備します。作業スペースにモジュールを書き出すためには NScvs checkout" コマンドを使います。ますモジュールを各内するためのディレクトリ ( たとえば、 ~ / cvswork とい、ったディレクトリを作るとよいでしよう ) に入り、そこで、 % cvs checkout claudia と、取得したいモジュールの名前を指定してコマンドを実行します。ここでも -d オプションで明示的にリポジトリの場所を指定できます。工竟変数などでリポジトリの場所を設定していない場合は、このオフションが必須になります。これが成功すれは、カレント・ディレクトリのなかに claudia という名前のディレクトリが作成されます。ディレクトリ中にはリポジトリに登録したのと同じファイル群が入っているはすです。また、 claudia ディレクトリ中に CVS という名前のディレクトリが作らオ L 、そのなかにリポジトリやモジュール内のファイルについての情報などが ↑褓内されます。これで、イ乍業スペースでファイルの処理ができるようになりました。作業スペースでは、ふつうにエデイタなどを使って新しいファイルを作ったり、ファイルの内容を修正したりしてかまいません。竹喋カ鮗った時点で、彳あする、、 cvs add" や、、 cvs commit" などを使って竹業内容をリポジトリに反映させれはよいのです。 99

8. UNIX MAGAZINE 2000年10月号

連載 /UNIX Communication Notes—O イルが BASE64 形式のまま保存されているものも数多い。この場合、添付されているファイルの内容を確認するには、メールツールを使ってファイルを取り出し、さらに適切なアプリケーションを起動しなけ川まならない。この作業はかなり面倒である。蓄積した電子メールを検索し、過去のメッセージを取り出す作業がよくおこなわれる。このようなことから、電子メールについては、フォルダに取り込む前のフィルタリン久スレッド単位でのマーキン久複数のメッセージに対する検索処理などか不可欠であろう。メールツールはたくさんあるが、これらの条件を満たすツールははとんどない。さらに、用負っすんだ電子メールは簡単に捨てられるかというと、そうはいかない。とくに、検索は過去に遡っておこなわれることもあるので、すくなくとも過去 1 年程度のメールには即座にアクセスできる環境がほしい ( 私の場合は、過去 3 年間のメールは即座にアクセスできる ) 。保存期間を 1 年に区切っても、そのあいだにやりとりする電子メールはかなりの数になる。とくに複数のメーリングリストに入っていたりすると、膨大な数のファイルを対象に検索しなけれはならない。 Web も困りもの描丘は、電子メールに Web ページへのポインタを書いてくる人も増えた。「こんな情報があった」ということを教えるためである。こうなると、電子メールを読み、さらにそこに記された Web ページで情報を読むことになる。しかし、 Web ページは消えてなくなってしまう場合もあるので、後日の検索などに備えてそのページを PostScript ファイルに変換したり、あるいは公開されている PDF ファイルなどをダウンロードして保存しておく。これもまたファイルを増加させ、なんのために保存したのかが分からないといった状況を生み出す。とくに、自分か読んだ電子メールと、 Web ページからダウンロードしたファイルやページを印刷した P 。 stScript ファイルとの相関関係か肥握できないのか、致イ髄勺である。 Web ページへのポインタを電子メールで送るのはたしかに便利ではあるが、ファイルの整理という点ではかならずしも歓迎でき 38 情報の整理整頓以のようなことから、私たちが日々使っているコンピュータ上にはファイルがどんどん増え続けていく。しかも、これらをうまく管理しないと、必要な情報をみつけるのに苦労することになる。そして、再利用か難しくなり、結果としてゴミの山を量産することになってしまう。不要な情報を溜め込み、身動きがとれなくなるような愚は避けなければならない。それには、もちろんューサー自身が知恵を絞り、日々のイ士事のなかで、、ゴミ " を減らす工夫をする必要がある。ただし、そのためのオーバーヘッドカ吠きいと、減量作業を続けるのは難しくなってしまう。さきほど示した、・ファイルの増加をどう防ぐか再利用可能なファイルをどのようにしてみつけるか再利用できないファイルをいかにして減らすかの 3 つの訝題をいかに角夬するかか鍵である。たんにユーサーの努力や注意に頼るのではなく、ツールを用いた効果的な竟を構築する合ま勺、かっシステマチックな鮹夬方法カ球められている。この課題の解決策として、これまでにさまざまなシステムが考案されている。なかには商用アプリケーションとして提供されているものもあるし、研究活動の一一環として開発されたシステムもある。次回からは、 UNIX 工竟におけるこの種のシステムを紹介していく予定である。 ( やまぐち・すぐる奈良崙科 ! 物支彳析大凝完大学 ) UNIX MAGAZINE 2000.10

9. UNIX MAGAZINE 2000年10月号

- けつま 3 びっド・師匠が用意してくれた CVS リポジトリから複製を作成 ( チェックアウト ) してから、複製で作業してその成果をリポジトリに応央させる・師匠の作業の結果を作業用の複製に反映するという作業の繰返しでした。そのうちだんだん慣れてきて、 CVS の機能を使って自分か書いた文章を師匠がどのように直したかを調べ、専門用語を憶えたり師匠好みの日本言韶 ) 使い方を発見したりと、徐々に CVS の利点を享受できるようになってきました。いまでは、師匠や他の人たちと共有するファイルだけでなく、自分だけで使っているファイルも CVS で管理することか増えました。、、 1 人て使うファイルにまでどうして CVS が必要なの ? " と思うかもしれません。私がなぜ CVS を多用しているのか、その便利さについて説明したいと思います。というわけで、今回のテーマは「プログラマーではない人のための CVS の活用法」です。 CVS の利点 CVS は、ソフトウェアの共同開発を目的に作成されたシステムなので、そのために必要な機能がいろいろ含まれています。ソフトウェアの開発中にはさまざまなバージョンのファイルが多数生成されます。 CVS は異なるバージョン間の関係を : 冓造で表現して扱えるようになっており、さまざまな状況てイ叫リに使えます。この構造によって、変更に関する里の系列か保存さオ・し、ある時点で別の系列への変更 ( 枝 ) が生した場合でも、両方の系列をうまく処理できます。いつ、誰が、なんのためにファイルを変更したかといった情報も言当求できますから、必要に応してそれらを確認したり、場合によってはファイルを以前のバージョンに戻したりもできます。同しようなバージョン管理システムには彳幻する RCS などがありますが、とくに CVS 独自ク芋徴として、・ディレクトリ構造の管理・ネットワークを介した避鬲管理への対応を挙げることかできます。このため、複数の互いに里するファイルを複数の人間で共同利用したり、異な 96 る場所にある複数の言算機でファイルを共有したりできるのです。でも、私にとって CVS の最大の利点は、容易にバックアッフ。がとれるバージョン管理で履歴を知ることももちろん重要ですが、とくに個人か所有しているファイルの場合は、それよりもこの、、複数の場所て 1 司し内容のディレクトリを系財寺できる " という致にお世話になることが多いのです。作業用ディレクトリでの作業結果を CVS リポジトリ中のファイルに登録すれば、作業用ディレクトリと CVS リポジトリの 2 カ所に同し内容のものか存在することになります。さらに別のディレクトリで同しファイルを取得すると、 3 カ所で同じ内容寺できます。これは一見冗長にみえるかもしれませんが、 CVS では遠隔地にある別の計算機で同じファイルを共有できるので、リポジトリとイ乍業用ディレクトリをそれそれ別の引・算機に置いておけば、どちらかか物章しても大事なデータを失わずにすみます。また、 OS を入れ替えたり新しいハードディスクを買ってきたときも、すぐにほは 1 司じ内容のデータを回復できます。ハードディスクが壊れるのを心配して定期的にバックアップをとるのはとても面倒な作業です。システムすべてとはいわないにせよ、自分の成果物や作業中のデータだけは事故があってもけして失いたくない、という願いをかなえてくれるのが CVS だと思います。とくに描丘では、 1 人で複数の計算機を所有している人も多いようです。私でさえ、多いときにはデスクトップ計算機とノート PC を合わせて 3 台も使っていました。ハードディスクの値段もたいへん安くなったので、大量のデータの保存には他のバックアッフ。用機器と同様に手軽に利用できます。かなり面に、また簡単に安じ、を買えることは、あまり触れられてこなかったにせよ、 CVS の利点の 1 つではないでしようか。 CVS の仕組み CVS のシステムを、、データの置き場所 " という視点でみると、リポジトリと作業スペース ( ディレクトリ ) に分けることができます。ー殳に、、 CVS を使う " とは、差分情報やファイル更辛刑のログ清報を言当求するリポジトリが UNIX MAGAZINE 2000.10

10. UNIX MAGAZINE 2000年10月号

連載 / BSD をハックする一のどの raw デバイスでは、大量のデータを扱うことか普通なので、カーネル内のバッフアにデータをコピーすることはせす、ユーサー空間のメモリをロックして掃き出されないようにしたうえで、直接装置とのあいだでデータを転送するようになっています。カーネル内バッフアのサイズより大きなデータを出力するときには、複数回に分けて (while ルーフ ) データをコピーします。こオ LJ ユ降は、カーネル内にあるデータを装置に出力する処理となります。 lptpushbytes(sc) には、割込みを使う場合と使わない場合の 2 つの処理が入っています。引数の sc は、 struct lpt-softc へのポインタです。 struct テンヾイス名ー softc" というのは、個々の装置に関する情報をイ褓内するための構造体で、 lpt の場合はデータバッフアへのポインタやバッフアの内容量などをオ褓内しています。ですから、 sc ただ 1 つを引数て渡せは足りるわけです。割込みなしの場合割込みを使わないときは、次のような処理をおこないます。これは、 DOS などシングルタスク OS のプリンタドライバとまったく同じです。 whi le ( テータがまだある ) { / * プリンタの準備はいいか * / while (NOT-READY() ) { ちょっと待つ ; データを出力 ; STROBE 信号を出力 ; STROBE 信号をオフにする ; これを具体的に書くと、次のようになります。 int ctl = 制御ポートの状態 ; while( i 取 b ( 0X378 + 1 ) & 0X80 ) { ちょっと待つ ; outb ( 0X378 + 0 , データ ) ; outb ( 0X378 + 2 , ctl ー 0X01 ) ; outb ( 0X378 + 2 , ctl ) ; inb と outb はバイト単位の入出力関数で、それぞれ CPU の inb 命令や outb 命令を呼び出すものとします。 NOT-READY ( ) は lptvar. h で定義されたマクロで、 (bus—space-read—l(iot , ioh, lpt—status) LPS_INVERT) & LPS_MASK 78 に展開されます。 bus-space-read-l をはしめとする bus-space- 機能群 ( マクロだったり関数だったりします ) で装置にアクセスするのが NetBSD ク芋徴てす。ひと目見て LPT の status レジスタから 1 バイト読み出しているのが分かりますから、ある意味では見通しはよいといえます。しかし最終的に対応しているイ吾の inp 命令までを辿ろうとすると、多段階のマクロ展開に阻まれて非常に分かりにくくなっています。 C のソースを読んでいて不明な言当をみつけたとき窈架求はなかなか面倒なものです。とはいえ、関数へのポインタさえ使っていなければオ録戒的に探すことができます。不明な関数呼出しは、マクロである可能性があります。そこで、だいたい次のような可能を考えて探してゆくことになります。・同一ファイル内の関数・同一ファイル内で定義されたマクロ・同一ファイル内で定義されたインライン関数他のファイルの関数・ヘッダファイルで定義されたマクロ・ヘッダファイルで定義されたインライン関数・アセンプラで書かれた手続き・ Makefile で定義されたマクロいすれにせよ同一ファイル内て定義されたものは、ファイルの地負から検索すればすぐに定義をみつけることができます。間題は、他のファイルで定義されたものです。とくに #include によるファイルのインクルードは多段階に起こるので、直接 C のソースファイルに書かれていないヘッダファイルも検索対象になってきます。また、 #if などによって〕尺的にインクルードしていると、さらに複雑になります。適当にあたりをつけて grep で探せは・みつかりますが、運が悪いとかなり手間がかかります。一気に最終的な展開結果を知るには C コンパイラの手を借りるのが一 -- ・番簡単です。そのためにはます、通常のカーネルの再構成の手順でカーネルを再コンパイルします。ここでは、カーネル名を SUGAR としましよう。ディレクトリ /sys/arch/i386/compile/SUGAR の下に多くのオプジェクト・ファイルとカーネルができます。 UNIX MAGAZINE 2000.10