Last modified: Mon Dec 25 2000
ソフトウェアをいじる話
これより古い/新しい「ソフトウェアをいじる話」は
「らんらんのLAN」の目次から参照できます。
最新の「ソフトウェアをいじる話」は
http://www.kmc.gr.jp/~ranran/memo/software.html
で参照できます。リンクされる方は目的に応じてURLを使い分けてください。
変愚蛮怒にみる X プログラミングのツボ
変愚の XIM 化で得たいくつかの教訓をここに記す:
- XIC (X Input Context。
XIMのインスタンス... とでもいえばいいのかなぁ?)
は XCreateIC の引数にウィンドウをとる。
これは多分 Input Context はウィンドウに関連付けされるもの、
ということなんだろう。
- *band の main-x11 は複数のウィンドウを持つが、
入力管理の主体は1つしかなく、
よってどのウィンドウでキーを入力しても同じ結果になる。
すなわち、「キーボードのフォーカス」という概念がかなりいい加減
(すくなくとも私にはそう見える)。
- ところが、XIM 化するとなると、IC
はウィンドウに関連付けしなきゃいかんので、
イヤでも「キーボードのフォーカス」を意識させられることになる。
- このICが無条件に特定のウィンドウに関連付けられてしまうのって
XIM の構造的欠陥なんじゃなかろーか、という気がしなくもない。
まぁフォーカスの合ってる窓とユーザが interact している窓が別、
という *band のデザインのほうが変態チックなんだ、
という話は大いにありそう :-)
- 実はこういう場合 SendEvent を使うのが正しい解なんではないか、
という気がちらっとしているのだが、SendEvent
のことをよく知らんのでとりあえずパス (^^;)
- WM が twm の場合、真面目に XWMHint を設定してやらないと、
同一アプリケーションのウィンドウ間でフォーカスが移動してもそれをアプリケーションに通知してくれないようだ。
- 私の開発環境で使っている fvwm2
は無条件にフォーカス変更を通知してくれてたらしく、
最初この問題に気付かなかった。
- どっちが正しいのか、とか他の WM ではどうなのか、
とかは未調査。
- WM によって動いたり動かなかったりするXアプリが世の中にあるのって、
ひょっとしてこのへんの処理がいい加減に作ってあるんじゃないだろうか...
という気がちょびっとした。深く検証してないから全然説得力ないけど。
- XFree86 4.0 は XMODIFIERS に @im=skkinput のように、
Input Method を明示してやらないと XIM が使えないらしい。
3.X の頃は「何でもいいからとりあえず使える Input Method」
という指定ができたのだが...
- XFree86 4.0 のヘッダファイルには XSetIMValues
のプロトタイプ宣言がありません。あきらかにミスです :-)
4.0.2 で直ったのかどうかは知りません。
どっかで新しめ(R6 以降ベース)で日本語で書いてあって何冊も分冊の「ない」
Xlib プログラミングの良い入門書を探して、真面目に勉強しようか... (え?軟弱?)
変愚蛮怒にみる locale の怪
- EUCコードの文字列を strstr にかけると、
2バイト文字の途中からマッチすることがあるらしい。
- 「永続」が「並」にマッチしてしまう、という話は
*band 的にはかなりウケます :-)
いや、これでハマった *band プレーヤーには笑い事じゃないでしょうが...
- (「永」の2バイト目と「続」の1バイト目で「並」のコードになってしまうってこと、要するに)
- あれ? でもたしか... (カタカタ...)...
おおぅ。ctype.h の関数は locale を認識するのに、string.h
の関数は locale を認識せんのか。
まぎらわしい仕様である。
- これも変愚でソースをいじっててハマったのだが、
EUCの漢字(っつーか2バイト文字)を処理しようとして、
if(isupper(c))then 〜 else 〜
とかいう分岐を書いたのだが、
2バイト文字(の1バイト目)の中にも isupper(c)
にマッチしてしまうコードがあってうまく動かず、
if(iskanji(c))then 〜 else 〜
のように最初に2バイト文字をチェックせなあかんのだ、
という貴重な教訓を得たのだった。
- glibc2.2 には wcsstr などの、string.h の関数の wchar_t
版があるようだ。
これを使えばいいんだろうけど... EUC と wchar_t
の相互変換ってどうやるんだ? iconv 使うんか?
よくわからんし、どうせ UTF だろうからめんどくさいし、
FreeBSD にはこのテの関数がないみたいだし。
- ctype.h の関数みたいに locale 見て勝手に判断してくれる
strstr はどっかにないのかなぁ... 自分で作る?
Netscape6 正式版
(注: 例によって Windows2000 上でのハナシなので、
他のOSだとまた事情が違うかも)
正式版が出たのでアップデートしてしばらく使ってみたのだが....
使えんまくり。はっきりいって PR の頃のほうが100倍(推定)マシだった。
- 履歴がちゃんと出るようになったのはまぁいいとしても...
- でもよく落ちる。PR の頃のほうがまだ安定してた気がする。
- 相変わらず Back/Forward ボタンがよく壊れる
(まともに機能しなくなる)
- フレームもよく壊れる
- 相変わらず日本語フォントが枠や窓やボタンからよくはみ出る
- URLのパースが腐っててまともにサーバにリクエストを送ってくれん(!)
自分でアドレス欄に直に入力してもダメだしハイパーリンクをクリックしてもダメ。
失望したので Mozilla の nightly build をとってきて試してみると、
何かこっちでも同じような症状がでる。
.... 今まで Netscape6 って
「Open Source の Mozilla をベースに Netscape(AOL)
が独自改良を加えたブラウザ」
だと思っていたのだが、
実は単に Mozilla の snapshot の外見だけちょっと細工しただけの代物で
「独自改良」なんてロクにしてないんじゃぁ...
これじゃほとんど詐欺だよ。世間で非難囂囂なのも当然かも。
ふと思いたったので、自分用の CVS のリポジトリを作ってみることにした。
今自分の CVS リポジトリを作るのに適当なディスクが部室にはない
(Disk Full ...)。
近いうちにファイルサーバがリプレースされればそこを使えるんだけど、
今はまぁ練習用ということで適当に空いてる(けど信頼性イマイチな)
HDD に作ってみる。
CVSメモ(1)
まず概念と用語
- リポジトリ [repository]
- CVS で管理されるファイル群の最も大きな単位。
cvs -d とか環境変数CVSROOT で指定されたディレクトリと根とするツリーからなる。
- モジュール [modules]
- CVS で管理されるファイル群の、リポジトリより1つ小さい単位。
リポジトリは複数のモジュールから構成される。
通常リポジトリ(の根になるディレクトリ)
直下にあるディレクトリ(とその下全体)を1つのモジュールとして扱う。
が、別途モジュールを構成するファイルを定義することも可能。
- 管理用ファイル [administrative files]
- リポジトリ(の根)直下の CVSROOT
というディレクトリに入ってる管理用のファイル群。
この CVSROOT というのもモジュールの一つになるので、
「管理用モジュール」といったほうがよいかも。
- 作業用ディレクトリ [working directory]
- 作業する人がリポジトリからモジュールのコピーを取り出しているディレクトリ。
作業している人の数(あるいはそれ以上)だけ存在する。
リポジトリを管理するためのコマンド(cvs のサブコマンド)
- init
- リポジトリを新規作成する。
具体的にはリポジトリとして指示されたディレクトリの下に CVSROOT
(管理用ファイル)が作成される。
- import
- 他所(リポジトリの外)にあるツリーをモジュールに取り込む。
普通は新規にモジュールを作成する時に一回だけ用いる。
モジュールを管理するためのコマンド
- import
- 他所で独立に管理されているツリーからモジュールを作る場合、
オリジナル側の変更を取り込むためにも import が使われる。
開発する人が使うためのコマンド
(基本的に作業ディレクトリを用意して実行するコマンド)
- checkout
- 指定したリポジトリから指定したモジュールの(部分)コピーを取り出す。
普通は新規に作業ディレクトリを作成するときに一回だけ用いる。
- update
- checkout 済の作業ディレクトリに対して使い、
(最後にupdate/checkoutしてからの)リポジトリ側の更新を取り込む。
- commit
- 作業ディレクトリの変更内容をリポジトリに反映させる。
- add
- 作業ディレクトリに新たに作成したディレクトリやファイルをリポジトリ側に反映させる、ことを指示する
実際にリポジトリ側にファイルやディレクトリが作成されるのはこの後で
commit した時。
- remove
- 作業ディレクトリから削除したディレクトリやファイルをリポジトリ側に反映させる、ことを指示する
実際にリポジトリ側からファイルやディレクトリが削除されるのはこの後で
commit した時。
- log
- 指定したファイルの更新履歴を見る
- status
- 指定したファイルの現在の状況
(作業ディレクトリ側の最後に update した時のリビジョン、
現在のリポジトリ側の最新のリビジョンなど)を表示する。
- diff
- リポジトリ側(の任意のリビジョンの時点のもの)のファイルと、
作業ディレクトリ側のファイルで差分をとる
- release
- 作業ディレクトリを消去する。
正確には消去しても問題ないか(未commitな変更が残ってないか、など)
をチェックするだけ。問答無用で rm -rf してもシステム的には問題ない。
バージョン管理に関する用語
- リビジョン [revision]
- CVSで管理される個々のファイルにつけられているバージョン番号。
他のファイルのリビジョンとは独立につけられる。
普通は(特に設定しなければ) x.y のような2つの数であらわされ、
書き換えられるたびに y が増えていく。
- タグ [tag]
- ファイルの特定のリビジョンに対して付けられた symbolic な名前。
複数のファイルに同じ名前のタグをつけてもよい。
この場合、同じ名前のタグでもファイルによって対応するリビジョンはバラバラ。
普通、
リリースするとかにモジュールのすべてのファイルに
(リリース名や日付をもとにした)同じ名前の tag をつける。
これによって後で「この時点でのツリー」を簡単に取り出せる。
- 枝(ブランチ) [branch]
- 同一モジュールの同一ファイルに対して複数のリビジョン管理(=内容変更)
の系列を用意したときの、それぞれの系のこと。
一番大元になる系(幹 [trunk])や、
他の枝の特定のリビジョンから分岐する形で作られる。
枝のリビジョン番号は、"[分岐前の元のリビジョン番号].[枝番号].y"
という形になる。
一部の開発者が自分(達)
だけの実験用に本流に反映させずにファイルを変更したいとき、
安定版と開発版の2つを同時に管理したいとき、などに使われるようだ。
例えば FreeBSD のソースの場合を見ると、
幹は -current になっていて、
-current から枝を分岐させて -stable 用としているようだ。
よって、FreeBSD のソースファイルの revision 表記を見ると、
-current のは 1.x のような数字2つの revision が、
-stable のは 1.x.2.y のような数字4つの revision が書かれている。
CD-ROM なしで Windows のインストール(PC-98の場合)
- 某PC-98のWindowsが入っていたSCSI HDDがお亡くなりになってしまったので、
内蔵HDD(Linux/98 で使っていた) の一部を借りて DOS と
Windows95 を放り込むことにした。
- ... のだが、この98 は CD-ROM を引っこ抜いて代わりに
PCカードアダプタをつけていたりする :-) さてどうしよ。
- とりあえず起動フロッピーで起動して、領域確保とフォーマットと sys
コマンドの実行だけやる。
- 次に Linux/98 を起動して、
さっき確保したパーティションを mount する
(注: 2.1.57 ベースだと FAT32 が扱えないよ)。
その後ネットワーク経由で CD-ROM の中身をコピーする。
- Windows用(になる予定の)パーティションから起動して、
さっきコピーした CD-ROM の setup.exe を実行する。
- ... あんましおもしろくなかった ...
最初は起動フロッピーをハックして独自のシステム復元のとこまで再現しようか、
とか思ったのだが、フロッピーディスクを hack
するのはトロくてやってられんので止め :-)
Solaris8 vs. FreeBSD4
- 今度KMCで新しいサーバを導入することになり、
部室に DELL の PCサーバがやってきた。
- これの OS を何にするかで Solaris8(for x86) と FreeBSD 4.x
に候補を絞ったのだが、この先でどっちに決めるかでモメる。
- 「サーバ」ということになっているが、
みんなでメールやニュースを使ったり、
プログラムの開発をしたりといろいろ使うので実際にはそのへんの使用感も考慮して決定しなければいけない。
(単に NFS でファイルサーバやらせるだけなら
「正統」の Solaris に FreeBSD ごときでは太刀打ちできん...)
- 部室は Linux マシンが多く、Linux に慣れたユーザが多いので、
プログラミング環境としても管理の上でも Solaris よりは FreeBSD
のほうが使用感が「近い」んじゃないかな、
というのが FreeBSD 派の意見。
- Solaris 派は Sun のブランドと安定性を支持していたのだが...
Sun WS でならいざ知らず、IA 版の Solaris
ってそこまで信用していいんかなぁ、という気もする。
- でも NIS,NFS,locale,pthread,Java の
「正統」の実装を持つ Solaris は、
サーバとしても開発環境としても確かに魅力ではある。
- 結局安定性についてはたかが KMC
の部室程度の規模ではどっちでも問題にならない(...はずだ)
ということになったのだが。
- いろいろ実験していて、実は Solaris8 の IDE(ata)
ドライバに「32GBのカベ」があることが発覚した。
- Solaris8 の新機能として「8GBを越える IDE HDD を扱えるようになりました」
とあるので、てっきり LBA 完全対応になったもんだとばかり思っていたのに...
- 現実には、8GB 超の HDD を Solaris8 に認識させると、
Head=16, Sector=63, Cylinder=(総セクタ数)/(16*63)
というジオメトリになるようだ。
しかし、Cylinder が unsigned 16 bit integer のようで、
32GB を越える HDD だと Cylinder 数が溢れて
modula 65536 な値になる :-)
BIOS で Cylinder が 16bit に収まるような適当な CHS
を強制設定してみたのだが Solaris8 は BIOS の設定を無視して
H=16,S=63 にしてくれるようで、うまくいかなかった。
- Solaris7 に 8GB
のカベがあったのもリリース当時の状況を考えるとかなり致命的だったけど、
今回のこれもかなりダメダメだ。
- Sun は
「けっ、SCSI も使えねーよーな貧乏人が Solaris なんかに手ぇ出すな」
とでも言いたいのだろーか....
よく HCL 見ると IDE の CDROM には言及しているが、
IDE HDD が「動く」とはどこにも書いてないし :-)
- ま、なんにせよこれで対立候補が自滅してくれたので、
サーバ OS は多分 FreeBSD で決まりでしょう。
- ちなみに NetBSD や OpenBSD にしなかった理由は、
locale や thread の実装が *BSD の中で一番充実していて
(まっとうかどうかはさておき)、
プログラミング環境として最も Linux に近そうだから。
- だったら最初から Linux にすればいいじゃんって?
... Linux にすると libc とか /bin,/sbin
の下の基幹バイナリを差し替えたくなるからダメっす :-)
- Linux を NFS クライアントにするなら Linux
がサーバでないとパフォーマンスが落ちてしまうんだけど...
ここで Linux の腐れ NFS に屈してしまうのはやっぱりヤだ。
- (昔から思ってたけど、Linux 陣営はことこの点に関してだけは Wind○ws
の「独自仕様で囲い込み」を非難できないと思うぞ...
Linux の NFSv3 パッチに期待)
knr2ansi(?) 追補
- 後輩Tくんからツッコミ。
「gcc の protoize ではダメなんすか?」
- .... なにー! gcc にはそんなもんがついとるんかー!
しらんかったー! (ってこれじゃ後輩Rくんだ :-))
- man がないので(まぁ GNU Product だしぃ) info
を読む... 確かに関数宣言を
ANSI準拠のプロトタイプ宣言に変換できるようなことが書いてある
- 実行してみると... うげ、フィルタじゃないのか...
しかも gcc 実行してるように見えるんですけど...
- 一応結果は cproto のときと一緒(というか、cproto
が protoisze を参考に gcc
をわざわざ実行しないで高速に変換できるようしたもの、
と考えたほうがよさそうだ)
- ... なんかこう、ansi2knr が C のソース一つでさくさく動くのに比べて、
「牛刀を以て鶏を割く」って感じがするんだけど...
実はそこまでやらなきゃいけないほど難しいのだろうか?
CVSサーバを立てよう(2)
- 後輩Yくんが、「cvs のはなし」
というページを見つけて教えてくれた。
- サーバの立て方については私が前にぼんやりと考えてたことと発想が同じだけどもっと徹底している。
chroot まで使うかぁ (^^;)
- でもモジュール毎に chroot
とかいいだすと外部バイナリの準備が面倒なことになる、
というのは wu-ftpd(not anonymous) + chroot
という、最近 Web サーバで多く見かける例を考えれば自明。
- 今の cvs はバリバリに外部コマンドに依存しまくりらしいからなぁ、
chroot までやっちゃうと面倒が増えるなぁ。
- ... となると、今まで外部コマンドでやっていたことをみんな cvs
内部でやる、という ProFTPD のような発想が必要になってくるんでないか、
という気がする。
- そこまでやるくらいだったら、ssh + portforwading + pserver
のほうがコスト低いかなぁ、という気がする。
Netscpe6 PR3
最近思いだしたようにWWWでょゎぃ画像の収集をはじめたので、
適当な GUI な WWW ブラウザを物色中。
ちなみに以下、基本的には OS は Win2k での話。
- Netscape Communicator 4.75
- 文字がよく化ける
(特にウィンドウを別に開ける時。
言語設定をいじっても化けたままのことも多い)
セキュリティホール対策も遅れぎみだし...
ま、Mozilla ベースの NC6
が本命らしいのでこっちのメンテナンスは手抜きなんだろう。
スタイルシートの対応はボロボロなので切って使うのが吉。
普段は JavaScript も切るのだが、
見るページの中身の傾向を考えると切ってるとロクなことにならないので、
仕方なく有効にして使っている。
- Netscape Communicator 6 PR3
- 「PRだけど4系よりははるかにマシ」
との後輩Y君の進言により試してみる。
- たしかに文字化けは滅多にないし、
スタイルシートの対応も比較的まとも
(でも IE とレイアウトが違うページがあるなぁ...)
- だが、表示が一部表示枠から切れてしまうことがある。
イメージマップが途中で切れてたりすると、
一部のリンクが手繰れなくて悲しい(;_;)。
プロパティの設定画面でも、
一部のオプションが枠から切れてて設定できない。
- あと、新しいウィンドウを開くとき元の窓にぴったり重ねてくれるので、
操作しづらいのも何とかならんかなぁ
(X ならこういうのはウィンドウマネージャの問題なんだろうけど、
Windows ではどうなのか知らん)
- フレーム付ページ内での Back/Forward ボタンが時々効かなくなる。
横っちょの一気に戻るほうは有効。謎だ。
- 履歴が一切保存されない。
履歴がないので、スタートページを「最後にいったページ」
にしても about:blank になってしまう。
- NC4 よりよく落ちる。
実用に耐えんほどじゃないけど。
... リリースまでには何とかなってるといいなぁ。
- Mozilla seamonkey (Milestone 17)/Nightly build
- Win2k では動かなかったのでパス
(今の Nightly build と M18 でどうなったかは知らん)
Unix 版はちょっと使ってみたけど、なんか動作が「もたっ」
としてるので、あんまし使いたくないかも。
(← Dual PentiumIII 700/FreeBSD 4.1-STABLE でこれじゃぁねぇ...)
- IE 5.5
- なんだかんだいっても、表示面ではいちばんまっとう。
ただなぁ、
セキュリティとか表示回りのオプションがどこまでユーザ固有になってるのかがよくわかんないんだよなぁ。
KMC で多人数で使う環境だとこれがいっちゃん重要だったりするんだけど...
今度真面目に調査の必要あり、かな。
で、結局今は NC6PR3 を使ってる。
今度 Mozilla M18 も試してみるか。
- NetBSD ML からの情報。
- FreeBSD や OpenBSD で取り込まれてる cvs は CVSROOT/options
でむにゃむにゃするとリポジトリローカルな tag が使えるように改造されてるらしい。
(FreeBSD では $FreeBSD$ とか使っとるし)
- ほしいぞこの機能! この部分だけパッチで分離されてないかなぁ...
後輩 Y くんに push してみやう。
- ついでに展開対象にする tag を取捨選択できるともっとよいなぁ...
- 某 Plamo の ML でUPX
という「実行ファイルの」圧縮ツールの存在を知る
- ... あ、LZO (←vtun などで使われてる圧縮ライブラリ)
と同じ作者なのか。
- 試しに手元の Linux マシンで make して emacs を圧縮してみる...
1/3強くらいに圧縮できた。
- これ起動ディスクとかに使えないかなぁ、と思ったのだが...
「Linux だとふつーRAMディスク使って、
フロッピーにはそのイメージを圧縮して書き込むから、
個々の実行バイナリを圧縮しても意味ないのでは?(by 後輩Tくん)」
... しまったぁぁぁ!!
- でもまぁRAMディスクを使わない場合
(Linux/98 の2フロッピー構成とか、NetBSD とか(←1.5ではどうなるんだろう?))
には役にたつだろうし、
RAMディスクでも自身の総サイズが小さければメモリの少ない98
では嬉しいだろうという気はする。
- ... なに? 「UCL (←UPX が使ってる圧縮アルゴリズム)
の展開ルーチンは小さく高速なので Z80 や 6502 でも動きます?」
(←かなり意訳)
... それは MSX で動かせということか? (^^;)
cron の困った仕様
- 最近不正メール対策で、Envelope FROM
の到達性をチェックするのが流行りだした(?)影響で、
KMC から送られるメールが不正チェックにひっかかる事件があった。
- KMC は kmc.gr.jp というドメイン名を京大からもらっていて、
これは外部にも公開されているわけだが、
実は部内ではさらに box2.kmc.gr.jp
というサブドメインを勝手に設定して運用されている
(昔部室が2つあったときの名残)。
- で、KMC のメールサーバは外へメールを出すときに、
一般ユーザがメールを出すときはドメイン名を @kmc.gr.jp
に変換するのだが、
システムアカウントからメールが出るときにはドメイン名が
@hostname.box2.kmc.gr.jp になる。
- 普通はシステムアカウントがメールを出す先は部内のサーバなのであまり問題にならないのだが、最近2つほど例外が発生することが判明した。
- 1つは、部で運用している news2mail。部のローカルの NewNews
の記事を、外の部員にメールで配送するサービスだが、
これの配信時の差出人がシステムアカウントの news さんだったりする。
- なので、Envelope FROM で
news@ニュースサーバ.box2.kmc.gr.jp
といって外にメールを出そうとしてエラーチェックに引っかかっとった。
- これは news をシステムアカウント扱いしないようにして解決した。
- もう1つは、cron。
cron は実行したコマンドの出力をメールで送るが、
これの差出人が root さんだったりする。
- なので、一般ユーザが cron を仕掛けて、
メールを外部に転送していたりすると、やっぱり Envelope FROM
が root@cronを仕掛けたホスト.box2.kmc.gr.jp
になってしまってエラーチェックに引っかかる。
- さすがに root をシステムアカウントから外すのはちょっとヤなので、
cron を仕掛けた人に連絡して、
コマンドの実行結果は自前で処理して(つまりコマンドの最後に
2>&1 | mail hoge をつけてもらう)、cron
には出力が渡らないようにしてもらった。
- 調べてみたら、cron の実行したコマンドの出力をメールするとき、
差出人を誰にするか、というのは cron の実装によって違うらしい。
- cron プロセスのオーナー(つまりroot)で出すもの
- NetBSD 1.4.1 の cron、Vixie cron
- crontab のオーナー(つまりそのコマンドを仕込んだ人)
で出すもの
- Solaris7 の cron、Dillon's cron
後者のタイプの cron では、当然こういう問題は発生しない。
- cron の実装にケチをつけるより、
部内のドメイン名もグローバルに引けるようにすべきなんだろうか
(昔はともかく、
今は外部に自前のサーバがあるから
DNSサーバを公開することは可能なんだけど...
セキュリティ上どうなのかなぁ)。うーん。
- automake の中には、ansi2knr という、ANSI
形式の関数宣言を昔懐し(?)の K&R
形式に書き換えてくれるソフトが入っている。
- ... んでは、この逆に K&R で書かれた関数宣言を ANSI
形式にしてくれるプログラムは?...
というと、ありそうでなかったりする(らしい)。
- ANSI とか K&R とかいうキーワードで Web
のサーチエンジンを探してもノイズが多すぎるし。
freshmeat や sunsite にもなさそうだし。
- ... FreeBSD の ports を漁ってみて、cproto
というプログラムをようやく見つけた。
でもこれも主目的はプロトタイプ宣言の自動生成で、
ANSI⇔K&R の変換はついでのような書きかた。
- 試しに実行してみると #include までご丁寧に見てくれるので、
glibc のヘッダにある __P((....)) の部分がおかしい、
とかいってワーニングの山を吐く。
include を抑制するオプションらしきものはあるんだけど、
指定しても効いとらんように見えるのだが...
- でもまぁワーニングがボロボロ出ても、
とりあえず変換はちゃんとできてるようだから、ま、いっか。
CVSサーバを立てよう
- 「部外の人とソース共有したいぞー」というリクエストがあったので、
CVS サーバを起こす。
- とりあえず設定が簡単なので pserver を使うことにした。
後輩Yくんに
Open Source Development
with CVS の日本語訳
(「CVS -バージョン管理システム-」という書籍のうち GPL
で公開されてる部分)
のページを教えてもらったので、
これを見ながら2人して(主に後輩Yくんが、だが)設定する。
- 他にも参考にしようとしたオンラインのドキュメントはあったが、
cvs のバージョンアップによって設定方法が意外と変わってるようなので、
古いドキュメントを見てもあまり参考にならない、
ということが判明(^^;)
- ポリシー設定
- 各モジュールごとに定められた人だけが checkout/commit
できる
- モジュールを新規に作れるのは cvs 管理者だけ
- CVSROOT を checkout/commit できるのは cvs 管理者だけ
- cvs 管理者は全モジュールを checkout できる
(commit はできない)
- cvs 管理者以外に checkout だけできるユーザは考えない
- anonymous CVS もとりあえずなくていい
- 結局やったこと。
- ユーザに cvs 管理者(cvs)と、モジュールごとに1ユーザ
(cvs-xxx) を追加
- グループに cvs 管理者(cvsadmin)と cvs 一般ユーザ(cvs)を追加
- .lock というディレクトリを作って cvs group writable
にしておく。CVSROOT/config に
LockDir=/var/cvs/.lock という行を追加
- CVSROOT/passwd を作成。
3番目にそのユーザがアクセスするモジュールのユーザを書いとく。
- 各モジュールのディレクトリは owner cvs-xxx
(そのモジュールのためのユーザ)、group cvsadmin、
mode 2750 にする。
- これで cvs-xxx は checkout/commit 両方可能、
cvsadmin は checkout のみ、それ以外はアクセス不可、
というポリシーが実現できてる、はず。
- cvs 管理者は pserver じゃなくて CVS over SSH
を使うので CVSROOT/passwd も CVS の管理下に置いてしまう。
このほうが新規にユーザを登録するとき楽だ。
- CVSROOT/Emptydir という謎なディレクトリができてる。
group writable になってるのがなんかヤだねぇ、
ということになって、
ドキュメントにも説明がよく書いてないのでとりあえず消してみた。
checkout がまったくできなくなった (T_T)。
しょうがないんで復活させた。
せめて LockDir みたく CVSROOT/ の外に出せればなぁ...
- 今の方法の問題点
- モジュール毎にユーザアカウントを作るので、
実質上 cvs 管理者 = root ということになる。
もともと管理用のしか shell account
は用意してないホストだからこれでも問題ないだろう。
- .lock が group writable なのはやっぱり気持ち悪い気がする。
どうせこの下にモジュール名でディレクトリが掘られ、
実際に lockfile を作るのはその下らしいので、
モジュールを新規に作成するときに、管理者が
/var/cvs 直下と別に、ここにも mode 700
でディレクトリを掘ってやればいいんでなかろーかという気がする。
- ユーザが1つのモジュールにしかアクセスできない。
基本的に KMC 内のプロジェクト1つにつきモジュールが
1つできることになるので、
複数のプロジェクトに所属している部員はどうすればいいんだろね。
... 多分 pserver じゃなくて CVS over SSH にするのが正しい。
- モジュール毎にアカウントを作ってるので、
そのアカウントで SSH をかけてもらえばいい。
個人鍵での認証を使えば複数のモジュールにアクセスするのも簡単
(自分の個人鍵のパスフレーズだけ覚えればいいから)だし、
誰がどのモジュールにアクセスできるかは、
/var/cvs/xxx/.ssh/authorized_keys で管理できる。
- でもって authorized_keys を cvs の管理下に置けると、
cvs 管理者でなくても、
各プロジェクトで独自にメンバの管理ができてさらによいんだけど....
CVSROOT/checkoutlist
みたいな機能が普通のモジュールでも使えたりしないのかな?
調べとこ。
- あと、この方法だと cvs-xxx に対して有効な shell
を設定しないといかん、という問題もある
... restricted shell が使えるかなぁ ...
- (... しかしこうやってメモしといても、やっぱり cvs
のバージョンが上がると役に立たなくなってるかもね :-))
- 上の Open Source Development with CVS の日本語版、
HTML はページが長すぎて参照が大変なので info を使おうと
texinfo ファイルをダウンロードしてきたのだが...
emacs 20.7 の texinfo-format-buffer では整形できない。
あれぇ?
- (texinfo って mule と emacs と makeinfo
でびみょーに互換性がない
(正確にはどれかが上位互換なんだろうけど...)みたいなのがヤダなぁ...
info 作るのに何使えばいいのかわかんないよ...)
- タイトルが2回出てるのに気がついてあわてて修正 :-)
... だけではナンなのでメモしとこ。
- bash には locale.c という locale と gettext
を扱うソースが入っているのだが、これ、
実は「shell script で gettext を使えるようにする」
ためのもので、bash 自身のメッセージは gettext化
されてないらしい(Tセンセに教えてもらった)。
- よっしゃ、これで bash に対する zsh
のアドバンテージが... (^^;)
zsh gettext化計画(2)
- configure で有効にできるようにファイルをいじる。
まだ autoconf は慣れないのでいじるのに手間かかるなぁ...
- ひととおりできた気がするので、
tarball
にしてみたりなんかする。
- (しかし誰か持ってくのか? こんなの :-))
- あとは bash のソースを参考にして .mo
を変数で選択できるギミックとかも入れたいなぁ。
でないと日本語メッセージカタログが一種類しか使えないし(ぉぃ)。
zsh gettext化計画 :-)
- zsh で前から欲しいと思っていたメッセージの
でじこ化
... もとい、日本語化をちょっと試してみる。
- gettext を使うことにしてちょっと info を読んでみる...
が、「ちょっと」では読んでもよくわからん :-)
- が、だいたい
- libintl.h を #include する
- [ #define _(str) gettext(str) ]
- gettext化したい文字列定数を gettext() [ないし_()]
で囲む
- main() の最初のほうで setlocale(LC_ALL, "") と
textdomain("名前") を実行しとく。
"名前" は普通アプリケーションの名前を使うっぽい。
- ソースファイルを xgettext にかけて .po の雛型を作る。
必要に応じて --keyword= オプションで gettext
以外に抽出したい文字列定数を引数にしている関数を指定する
- できた .po ファイルを編集する
(Emacs の PO-mode は使いかたがようわからん...)
- .po ファイルを msgfmt コマンドにかけて .mo ファイルを作る
- .mo ファイルを /usr/[local/]share/locale/ja/LC_MESSAGES/xxxx.mo
という名前でコピーする。
xxxx は textdomain() で指定した「名前」にする
とするとアプリケーションを gettext 化できるっぽい。
- zsh のソースをざっと眺めて、とりあえず Src/utils.c:zerrmsg()
で gettext() を噛ませて、Src/init.c:main() に textdomain("zsh")
を入れとく。
- これでちょっと試してみると... あれ?メッセージが変わらない...
あ、LANG が C にされてる... 起動後に LANG=ja
としてみるとちゃんとメッセージが変わるようになった。
- が、zsh は tcsh ほどメッセージの分離が徹底してないので、
エラーメッセージ以外の部分はこれだけでは gettext 化できないようだ。
- 今 KMC で zsh 使ってるのは私だけ。
tcsh みたく変なカタログをいっぱい作ると zsh が普及する... かなぁ?(^^;)
- とりあえず作りかけの日本語 po
とか置いてみる...
全部じゃなくても、こんだけ日本語化できればだいたい OK かも...
Semi-gnus(T-gnus)
- 最近(といっても半年ほどたつが...) T-gnus
に乗り換えたので、しょっちゅう snapshot
を取ってきてアップデートしている
- が、一部のマシンでは T-gnus を make しようとすると、
"emu-e20 が開けん" とかいって byte-compile に失敗する現象がおきる。
- gnus のソースや emacs20 の lisp,site-lisp を漁って(grep かけて)も、
そんなファイルを読み込んでいる部分が見つからない。
- ほとほと困りはてていたのだが、
「ひょっとして変なとこに load-path が通ってて、
同名のファイルを変なとこから読み込んでいるんではないか」
と思いあたる。
- で、load-path を調べてみる。
byte-compile 時には -q とか -no-site-file
とかオプションがついていて、~/.emacs
で指定している自分の home directory の下の elisp とかは影響しない
(... はずだ)。実際 emacs -q -no-site-file で起動した時点で
load-path をチェックすると、/usr/local/share/emacs/site-lisp
とか /usr/local/share/emacs/20.7/lisp
とか見慣れた標準のディレクトリしか入ってない。
- が、ここで emacs -q -no-site-file で起動して手で dgnushack.el
を読み込ませてもう一回 load-path を調べてみると...
「なんじゃこの /usr/share/emacs/site-lisp ってのわ!」
そういうことだったのか...
- 詳しく解説すると、問題が発生するマシン(某 Linux マシン)
では、/usr 直下にディストリビューション標準で
mule2.3(19.34ベース) が入っていたのだ。
- で、このマシンに、私は emacs20 を /usr/local
の下に手でインストールして使っていたのだ。
- ところが dgnushack.el が勝手に /usr/share/emacs/site-lisp
を load-path に付け加えてしまったので、emacs20
環境なのにもかかわらず、旧世代の elisp (tm とか tm とか tm (^^;))
を読み込んでトンデモナイことになっていたらしいのだ。
- 当然、/usr/share/emacs
が存在しないマシンではまったく問題なくコンパイルできていたわけだ。
- で、dgnushack.el の該当箇所を修正したらちゃんとコンパイルできるようになった。
この時 dgnushack.el を見てわかったが、/usr/share/emacs/site-lisp
を、問答無用で path に追加しちょる。条件判断とかオプション指定でどうとかいう制御すらしてない。
うぅ、やめてほしいな〜、こういうの。
apache の suexec
- KMCのWWWサーバ移転に伴ない、
専用サーバに apache をインストールした。
- が... CGI がどうもうまいこと動いてくれない。
いろいろ原因を調べた結果、suexec
がチェックに失敗して実行を拒絶しているようだ。
- ページの移転をアナウンスするために、
http://www.kuis.kyoto-u.ac.jp/~kmc/ 以下へのアクセスをすべて
1つのCGIにトラップして、
自動的に移転後の該当URLを含めたアナウンスを生成するようにしている。
- のだが、apache の suexec は /~kmc/ のように ~
を含んだURLのCGIに対しては、${kmcのHOME}/public_html/
の下にCGIの本体がないと実行させてくれない。
- で、CGI の実体(とかWWW用のコンテンツ全部)は
/www という別のパーティションに用意していたので、
ここでチェックが失敗していたようだ。
- この問題は ~kmc/public_html を作って CGI
の実体を移動して解決した。
/www の下しか部室内のマスターからのミラーをしてないので本当はヤなんだけど、
まぁ移転のアナウンスのためのCGIという一時的なものなので目をつむる。
- しかし、今度はメンバーのページ一覧(/Members/)のページで使ってるCGI
がチェックに失敗した。
- このCGIは HTML の中で <!--#exec cmd="../......">
を使って相対パスでCGIの実体を指している。
- suexec は CGI のパスに "../" を含むパスや絶対パスを認めていない
(つまりカレントディレクトリとその下のディレクトリだけ)
のでこういうことになる。
- こっちは対処しようと思うとWWWのページ構成を全体的に見直す必要がある。
それに、対処してしまうと CGI の場所が分散してしまうという問題が出る。
- なので結局、suexec を削除して使えなくしてしまったのだった。
- suexec は多分一般ISPのように
「多数のユーザがサーバスペースを共有してWWWコンテンツを立ち上げている」
という状況を想定してセキュリティポリシーが決められているんだろう、
と考えるとこのポリシーにも納得がいく。
- しかし、KMCのWWWコンテンツは
(内部には多数の各ユーザが管理するコンテンツがあるが)
システム的にはすべて同一のユーザが所有するファイルツリーで構成されているので、
suexec のポリシーとは合わないのだ。
うん、そういうことにしておこう。
- が、この間 apache のパッケージをアップデート
(Debian GNU/Linux を使っているので...)したら、
suexec が復活してしまってて、
この間の落雷停電でサーバが再起動したときに suexec
のチェックがしっかり復活してしまっていたようだ...
- というような事情があったんで、
先週末くらいから今日くらいまでKMCのサーバが落ちてたり、
いくつかのCGIを使ったページが表示できなかったりしていたと思います。
皆さん、ごめんなさい...
目次へ