グランドキャニオンのグラベルコースをインプで 1周． うー，グラベルは苦手だ．ミリ秒を攻めるブレーキング勝負の方が楽しいよー．
遅くに帰って時間なかったので，あまりプレイしなかった．ので，クリアはしてません． や，「クリア == ゴールド取得」なので念のため．
ご飯を炊いて，鯖の水煮の缶詰でうまうま．
PEAR の DB モジュールで oci8 つまり oracle8i にアクセスしていたら，
なぜか getOne() が動かない．
同じ SQL で prepare() → execute() するときちんと動く．
あるいは，バインド変数を使わないで値を埋め込むと動く．
何これ．
またもや調査．うーんうーん．どうやら，DB/oci8.php の
freePrepared() の中で ocifreestatement() しているのが良くないみたい．
どうもこの時点で statement だけでなくバインド変数まで free されてしまっているように見える．
これ oci8.php のバグじゃねーのー？
や，oci8 としては仕様なのかもしれんけど，
実際，PEAR::DB の機能として正常に動いていないわけで．
つってもこんな明白なバグが放置されてるとは考えにくいんで，
まぁここの環境とか oracle と liboci8 のバージョンとか，色々と絡むのかもしれん．
で，まぁ例によって DB/oci8.php をいぢってしまえば解決なわけですが，
ここはひとつ，最近話題の MDB モジュールの方を試してみましょうよ．
幸いにも pear install コマンドが使えるようになったので導入も楽々だ．
で，導入っと．使い方は基本的には PEAR::DB とほとんど変わらない．
$mdb = MDB::connect( 'datasource name' );
$hoge = $mdb->getOne( 'select hoge from moge where fuga = ?', null, array( $fuga ) );
PEAR::DB と違い，
getOne() の第二引数は，リザルトの変数型の一覧を渡すようになっていて，
バインド変数の一覧は 3番目の引数で渡すようになっている．
っていうか，ほとんどのメソッドではバインド変数を渡すことができなくなっている？
んー，query() でこれが渡せないと，
insert 文とかを作るのがめんどくせーのですが．
いちいち prepareQuery() → execute() しねーとダメですかそうですか．
パンフとかを収める紙のファイルがありますわね． いわゆる「クリアファイル」の紙バージョンみたいの． アレのことを「たとう」という……って話を同僚Ｔ氏がしていたのだが， 語源は知らないという．英語でも漢字でもない，と． なんで皆さんこういうのの語源を知らないまま語を使用できますカ！？
ってわけで調べてみました．知ってる人は読み飛ばしなさい． まず「たとう」の紙を「たとう紙（たとうがみ）」というらしいので， その辺で検索すると，和服を収納する際に包むための紙のことを「タトウ紙」と呼ぶらしい． ってことは和語なのだろーか． であれば，goo の国語辞典で検索．
〔「たたみがみ」の転〕 (1)詩歌の詠草や鼻紙などに使うため、畳んで懐に入れる紙。ふところがみ。懐紙。たとう。 (2)厚手の和紙に、渋・漆などを塗り折り目をつけたもの。結髪の道具や衣類などを入れるのに用いる。たとう。
あー，「畳み紙」の転語だったのか．なるほどなるほど．
「たたみがみ」から転じたとあるけど，これ，元は「たとみがみ」だったんじゃないかな． 「たとみがみ → たといがみ → たとうがみ」と． まず m が欠落して，次に連母音 oi が ou に変化ね． 「たたみがみ」なら「たたまがみ」か「たたんがみ」辺りになりそうだしな．
ところで検索中にすごくケッタイな画面を見たので保存しておこう．
なんだか，pear コマンドで install しようとするとエラーになる．
家や社サーバでは大丈夫で，社のローカルテストマシン（ Miracle Linux 2.0，PHP-4.3.1 ）でだけおかしいみたい．
pear install しようとすると，
「Could not get contents of package "～～.tgz" Invalid tgz file.」とか言われる．
ってことで調査してみますよ……
まず件のメッセージで grep -R 'Invalid tgz file' /usr/local/lib/php/* とか実行．
メッセージは /usr/local/lib/php/PEAR/Common.php にあるらしいです．
該当箇所をチェック．
$tar = new Archive_Tar($file);
if ($this->debug <= 1) {
$tar->pushErrorHandling(PEAR_ERROR_RETURN);
}
$content = $tar->listContent();
if ($this->debug <= 1) {
$tar->popErrorHandling();
}
if (!is_array($content)) {
$file = realpath($file);
return $this->raiseError("Could not get contents of package \"$file\"".
'. Invalid tgz file.');
}
えーつまり，$tar->listContent() がエラーなのでこのメッセージになってるわけだ．
PHP の PEAR ライブラリは，バイナリとかではなく全く完全な PHP コードで書かれているので，
/usr/local/lib/php からカレントにコピーしてきてやって，
そっちを好き放題にいじりつつデバッグ出来るのです．
この場合にはカレントに Archive というディレクトリを掘って Tar.php をコピーしてくる．
（include_dir はデフォルトで先頭に "." がいるのでこちらが優先して読まれる）
ってことで，ここんとこで print_r( $tar ) してみると，
どうも $tar->_compress_type が none になってるよ！
gzip 圧縮されてるのを素の tar だと思い込んで構造をゲット出来てなかった模様．
で，次に Archive/Tar.php の gzip 圧縮自動判定部分をチェック．
if ($fp = @fopen($p_tarname, "rb")) {
// look for gzip magic cookie
$data = fread($fp, 2);
fclose($fp);
if ($data == "\37\213") {
$this->_compress = true;
$this->_compress_type = 'gz';
$data == "\37\213" って辺りがぷんぷん臭うですよ．
しかし確かに gzip のヘッダは 0x1F 0x8B なので，これ自体が間違ってるわけではない．
ここんとこの比較で何故か失敗してると見た．
で，アレコレ調査してった結果……
どうも "\37\213" という表記で生成される文字列が，
その通りのバイト列になってないようだ．
さらに調べると，どうも 8bit 目が 1 の文字コードがシカトされて，
この文字列は "\37" という文字列になってしまっているらしい．
何でだ？ バグかと思って PHP-4.3.4（現時点で最新）をビルドしなおして確認したけどやっぱダメだ．
ま，とりあえずここんとこを直しちゃえば動くわけなんだけど．
if ($data == sprintf( '%c%c', 037, 0213 )) {
$this->_compress = true;
$this->_compress_type = 'gz';
これで動くようになった． や，なった，って，なんでこんなことになっちゃってるのかの原因が不明なんですが……(笑) なんかライブラリの方がおかしいのかな……うー他のマシンでこの現象が出ない…… マシン環境によるものなら，とりあえずこのマシンでは上記の問題は理解＆解決したので， 放置しちゃおうかしらん(笑)