Perlと限っているわけではない。Perlではないが有用だからこそ、標準モジュールになったりする。標準でないと、後からの追加には権限が必要になるからだ。こんな当たり前のことに気づかないとは、久しぶりの大ポカだった。その後もネイティブモジュールの使用部分を互換コードに置き換えたりしていったのだが、途中で限界を感じた。やろうと思えば動作自体は可能なのかも知れないが、スタブモジュールや回避コードを書けば書くほど、エミュレーション故のセキュリティの低下や効率の低下が気になる。FSWikiも標準モジュールも書き換え過ぎて、グダグダ感が出てきたところで諦めた。そもそも標準モジュールの構成をきちんと知らないから、スタブを書くにしても依存関係を何処で切ってスタブに置き換えるべきか、良好な判断が下せない。標準ライブラリという意味では、これがC言語だとしても似たような状況だろう。C言語の標準ライブラリがどのような構成で作られているかを子細に把握している人は、現在ではとても少ない。筆者はANSIが標準(C89)を定めてしばらく後の世代なので、普通に使っている限り、C言語の標準ライブラリの構成を気にすることは殆ど無い。昔はコンパイラ製品に標準ライブラリのソースが付いていることが重要だったりもしたのだけれど。昔は各コンパイラでライブラリの実装がバラバラで、かつメモリが非常に狭かったので、標準ライブラリから不要なものを削ったり、改造するなんてのも特段珍しくもなかった。筆者は初めて持ったPCがPentiumでWindows万歳、32bitリニアアドレス空間+仮想メモリ万歳の世代なので、C++でSTLでも使わない限りは標準ライブラリの問題なんて殆ど感じたことがない。Liteを使用することになった。LiteはフルセットのFSWikiが動かない環境で動作させる意図があった(むしろ@niftyが重要なターゲットだった?)らしく、ひとまず動かすだけなら簡単だ。PDF出力やRSS対応機能などは使えないし、プラグインを追加するにはゴリゴリとコーディングしなければならないが、標準モジュールと格闘するよりはこちらの方がよほど楽だった。Liteにはログイン機能がなく、従って管理画面もないのだが、その程度なら過去のコードから引っ張ってこればそれほど苦労しない。最初からこうしておけば半日を無駄にせずに済んだのに。いう訳で、フルセットのFSWikiを@niftyに設置しようとすることを、猫科研究所はお勧めしない。し、もしできたなら、お裾分けをお願いしたい。Perl5.010001。