あーありがち

過去の日記 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ squeeze を使って検索できるように

squeeze を使った出力で年ごとにディレクトリを区切ったまま、ちゃんと CGI 本体へのリンクを作る方法は？

なさげ。設定ではどうにもならないので、テーマと同じで、年のディレクトリの中に tDiary 本体へパラメータをそのまま渡すだけの CGI を置くことにする。

Namazu も Google も期待できないが検索したい

msearch ってのがあるらしい。

• • msearchを使って検索機能を作りたいのですが
  • msearch導入記

index.html へ静的 HTML へのリンクを自動生成

する処理を自宅サーバで動かせばいいような気がしてきた。msearch は msearch で動かしたいけど、まぁそこはそれ。

_ perlsh を OSX 10.3 + PPC 環境にインストール

なんか psh は高機能すぎて目的と違う気がしてきたので、結局最初の予定通り perlsh をインストール。以下手順。

1. cpan から install Term::ReadLine::Gnu
2. OSX 10.3 + PPC 環境では readline.h が見つからずに compile 失敗
3. 手元に Fink で入れた Readline があったので、それを使って compile
4. perlsh スクリプトを PATH の通ったところへ install

3 では

~/.cpan/build/Term-ReadLine-Gnu-1.16

に入って

perl Makefile.PL --prefix=/sw
make
sudo make install

Fink じゃない人は /opt とか適当に書き換えるよろし。

4 では

cd eg
sudo install -m 0755 perlsh /usr/local/bin

あと。perlsh は

#! /usr/local/bin/perl

になっているので、これを自分の使っている Perl インタープリタのパスに書き換えてやる必要あり。

僕にもできた。

ただ。これがどれくらい便利なのかはまだよく分かりません。

ちなみに、インタラクティブに Perl を使いたい場合、選択肢はまだまだあるらしい。psh の中の人が書いた

psh - Perl SHell

のいちばん下の方にある比較表が役に立つかも。

[追記] てゆーか fink に term-readline-gnu-pm581 があった。これならコンパイルエラーとか考える必要なかった。ただ結局ソース手に入れて eg/perlsh をごにょごにょ、っていう手順は必要だけど。

_ インストール済みモジュール一覧

use ExtUtils::Installed
$installed = ExtUtils::Installed->new()
$installed->modules()

で採れる。static に呼んでも採れないっぽい。

.perlshrc

に2行目まで書いておくと楽かも。my つけちゃうと実行後解放されて呼べなくなるので注意。

perldoc perllocal 方式はなんかよく分からなかったので別解を探しましたとさ。これで少しは楽になったかも。

※ 不要になった psh は make uninstall しようとしたらそのやり方は古いからダメって怒られ、結局削除されないのんで、locate psh で探しまくって削除しまくりました。

_ periodic_forwarder を書いた

cron シリーズ、何個目だ？

以前から cron の管理が面倒くさいことは書いているのですが、periodic, run-parts を利用することで厳密な時間設定の必要ないスクリプトの管理は比較的楽になりました。しかし、すべてのスクリプトがシステムワイドな cron ディレクトリにあると都合の悪い場合もあります。

そこでこんなものを書いてみました。

/lang/ruby/misc/periodic_forwarder CodeRepos::Share

どういうものかと言うと、

/etc/periodic/
|-- daily/
|   `-- periodic_forwarder*  ->  periodic /BASE_DIR/foo/FILLING_PATH/daily/
|-- monthly/
|   `-- periodic_forwarder*  ->  periodic /BASE_DIR/foo/FILLING_PATH/monthly/
`-- weekly/
    `-- periodic_forwarder*  ->  periodic /BASE_DIR/foo/FILLING_PATH/weekly/

こんな感じで、システムワイドな cron ディレクトリにこのスクリプトを置いておく（実際には link で ok）と、任意のディレクトリにこれを forward して、対応する period のスクリプト群を periodic, run-parts によって実行してくれるというものです。

※ 上の例は *BSD フレーバーなシステムの話ですが、Linux の /etc/cron.*/ 方式にも対応しています。

どういう場合に便利かというと、例えば

/var/www/HOST1/
/var/www/HOST2/
/var/www/HOST3/
/var/www/HOST4/

みたいに virtual host が設定されているとして、これらの HOST ごとに異なる仕事を定期的に実行させたいときなどに威力を発揮します。

/var/www/HOST1/cron/
`-- daily/
/var/www/HOST2/cron/
`-- weekly/
/var/www/HOST3/cron/
`-- daily/
/var/www/HOST4/cron/
`-- monthly/

こんな感じで定期実行するスクリプトを置くディレクトリを用意したら、

BASE_DIR     = /var/www
FILLING_PATH = cron

となるように設定してこのスクリプトをセットしておきます。

これで、ある HOST のための cron ジョブはちゃんとその HOST 用のリポジトリの中に収めておくことができます。

設定をスクリプトと分離する処理はちゃんと書いてない*1ので、ちょっと中身を書き換えてもらわないといけないですけど。すいません。一応起動時のオプションで設定を与えることはできるようにしてあるので、お試しで動かすことはできると思います。

とりあえず自分はこれで目的が達成できそうなので、今は結構ホクホクしています。

しかしこういう、

• オプションを指定できる
• ディレクトリを自前でなめる

ものをシステム管理的によく書くのですが、どうも自分はこの二つが同時に入っているコードのテストを書くのが苦手です。Rake とか使ってコードを置くディレクトリからテスト用のコードを生成するとかすればいいんだろうけど、面倒くさくなってベタで書いちゃうからテストを公開できなくなっちゃうんですよねぇ。うーん。まだ全然へたくそだ。