ラスカルが死んだ。
ってゆーか、 rascal.jaist.ac.jp (www.ldl.jaist.ac.jp) 上にあったページが消えた。 これは春の風物詩であるところのアカウント抹消に伴うもの... ではなく、 マシンのリプレースに伴うものである。 つまりリプレース時に、いない人のデータを保存しなかったわけである。
ページが消える可能性があることは 3月くらいから書いて警告しておいたし、 厳密な日時こそ知らなかったものの、 そろそろリプレースが行なわれることも知っていたし、 バックアップも手元にあるし、 問題はまったくない。
ひっじょーにささいな問題としては、 あそこは gs の vflib パッチの一次配布元であり、 現在のところそれに代わる場所は存在しない、 ということはあるかもしれない。 まぁ、tarball 自体はどこにでも転がっているし、 6.01 用のパッチは他の人が配布しているし、 もはやどうでもいいことであろう。
gs6_20 という tag がついていることに気づく。 これをもって gs6.20 がリリースされたといっていいのだろうか?
configurable mail filtering language 期待してます。 やっぱ .procmailrc を保守するのは疲れますよねぇ。
今は CyberDeck なので、メールの分類の設定はほとんどしてないんですが、 やはりもうちょっと気楽にいじくれたほうがいいのかもしれないという気もかすかにしますし。
ふと思いついたのだが、オプションの補完をする場合、 現在は、決めうちしてしまうか、あるいは --help などで出てくるヘルプメッセージを解析して存在するオプションを調べている。
しかし、これはいろんな OS, いろんな version に対応しようとするとかなり厄介な作業である。 とくに、手元にない OS の挙動は調べようがない場合がある。 (実際 _patch を書いた時にはもともとの配布を遡って調べただけでなく、 各 BSD の cvs tree を探り、また、利用できる範囲で商用 Unix も調べた。 実際、それぞれでかなり異なり、とくに、BSD は古いバージョンから枝別れして拡張されている。)
しかし、もし getopt (ないし getopt_long) などがオプションの情報を適切なフォーマットで出してくれるなら そちらの方が簡単確実でいいに決まっているわけである。 LD_PRELOAD あたりでどうにかできそうな気がするけれど。
もちろん、補完に必要な情報は getopt_long に与えられるものでも足りないわけで、 そのような情報も与えられるようなオプション解析ライブラリがあるにこしたことはないのだが...
後から気づいたのだが、 Linux 以外では(ってゆーか glibc を使っていないシステムでは) getopt_long がコマンド本体にはいってしまうから LD_PRELOAD では override できないんだな。ちっ。
まぁ、getopt については動くから意味がないというわけでもないか。
ついに cvs-info の形式を大幅に変えてしまう。
スレッドが できたようにみえたのは単に Subject: ごとにまとまっただけで偶然でしょう。 Subject: には log (の一部)が入るため、一般には commit ごとに異なる Subject: になり得るので、 スレッドになることは保証されません。
本当にスレッドにしたいのなら、各ファイルの各ブランチ毎に最後の commit に対応する Message-ID: を 記録しておいて、References: をつけるということが考えられます。 実装はそれほど難しくないと思いますが、 メールの関係が DAG になるので、どんな表示になるかはちょっと興味深いですね、 (どーせ References: の最後の Message-ID しか見ていないに違いないけどさ...)
実装してしまった...
_gzip を書くのに、 optioninfo を使って (_arguments に与える引数の)雛型を生成してみた。 ちょっと便利かも知れない。 まぁ、どんなコマンドにでも使えるというものではない(とゆーか使えないものが結構ある)上に、 環境を選ぶからあまりいいツールじゃないよな。
それはそれとして、_arguments は 9割くらいの状況にはうまく適用できるけれど、 残り 1割に対してはどうしようもないという拡張性のなさが気に食わないよなぁ。 まぁ、必要なら _regex_arguments に逃げられるからいいけれど、 他の人は気にならないのだろうか...
tarball の一部分を任意の場所に直接展開する方法はないものだろうか?
つまり、zsh-cvsroot.tar.gz の中に zsh/CVSROOT/ や zsh/zsh/ という directory が入っていたとして、 zsh/zsh/ の中身だけを xxx という directory のなかに入れるとか...
ふと、$PPID をつかえば process group に頼らずに 一つの commit から起動した commitinfo/loginfo が検出できることに気づく。
これで inetd から起動した場合も cvs 本体に手を入れずに commitinfo/loginfo を確実に動かせる... とはいえ、どーせ他の理由で手を入れるし、 /bin/sh が PPID をサポートしていないと動かないし、 あまり利点はないかも知れない。
さらにいえば commit がかち合うほど忙しくない server ではあまり影響はないし、 そもそも pserver 経由で commit するってのが論外という話もある。
% ash -c 'echo $1' a b c a % bash -c 'echo $1' a b c b % pdksh -c 'echo $1' a b c b % zsh -c 'echo $1' a b c bがーん。 (なお、Boune shell および ksh もやはり b を出力する。)
むぅ。なんだ Kondara の(ってゆーか RedHat の?) ash が古いだけか。 FreeBSD 3.4 でも NetBSD 1.4.2 でも Debian (ash-0.3.5-10) でもちゃんと b が出る。
まぁ、一元化された配布元が無い弊害という奴だな。
cvsweb のパッチを送りつける。
viewcvs で enscript を使って elisp に色をつけてみる。 これもパッチを送りつける。
ついでに _enscript を書く。これもまた送りつける。
さらに、elisp.st が ?\" を文字列のはじまりと認識してしまったので修正する。 が、これは送らない。まだ。
cvs で Checkin-prog と Update-prog をサポートしないようにするパッチを送る。
[latest]