kubotaの日記： lvの改造計画

lv (ほかにもこことかこことか) の改造だけど、以下の2段階にわたって行おうと思っています。

1. 世界中で広く使われているエンコーディングを追加
2. 出力エンコーディング決定メカニズム (従来の設定に基づく方法に加え、デフォルトではロケールから決定するようにする) と、入力エンコーディング決定メカニズム (従来の設定と自動認識に基づく方法に加え、ロケール情報も参考にするようにする。自動認識についても手を加えて東アジア人以外は使えない状況を解消する) の変更

ところが、第2段階のほうが先にできてしまい、第1段階のほうが難航している状況です。

ISO-8859-{10,13,14,15} については gotom さんによってすでに追加済み (だけど、upstream に統合されてないのはなぜだろう。たんに連絡してないだけか、連絡したけど反応がないのか、それとも何らかの理由で拒否されたか...) なので、それと同様にすれば ISO-8859-{11,16} も追加可能のはず。

しかし、ISO-2022 に基づかない8ビットエンコーディングの追加は、どのようにすればいいのか、よくわかりません。具体的には KOI8-R (ロシア)、KOI8-U (ウクライナ)、CP1251 (ブルガリア) くらいを追加したいと思ってるんだけど、さてどうしたものか。

(ほんとは、Big5HKSCS とか GB18030 とかも追加したいけど、難しそう)。

ちなみに、Debian JP Devel ML で情報を流してます。Unicode とハングルに関する不具合も見つけたんだけど、なぜいままでバグ報告がなかったんだろう。Jungshik Shin さんとかはもう見つけててもおかしくないんだけど。

upstream

[Anonymous Coward]

つか、upstreamはほとんど動きがないように見えるのですが。約3年ぶりの新しいリリースが5月に出たので、 一応成田さんによる保守は続いているということなのでしょうが、4.49.4から4.49.5の変更点は

* Don't read .lv located at the current directory, except for MSDOS. This fix prevent possible local root exploit using config files (CAN-2003-0188).

これだけです。だいぶ前にlvのライブラリ化の話とか、 iconv()のある環境ではiconv()を使うようにするらしいという話をきいたことがありますけど、それらは未だに実現していません。やる気があるなら、take overすることを考えた方がよいのかもしれません。

Re:upstream

[kubota (64)]

うーん、ぼくは lv の内部構成がさっぱり分からないので、take over は考えてません。そもそも、lv が片付いたら次は less に着手だ、とか思ってるくらいですから。(こっちは文字の分類を table[256] で持つという極悪な仕様なので、どうなることか分かりませんが、とりあえずロケール自動認識 lv ができたら、「ほぅら、これって便利だろう? less にもこんな機能ほしいなぁ」という議論をしてみようかなと思ってたりして。)

本人に聞いてみないことには仕方がないですが、できればパッチの受け入れとかは、やってくれればなあと思ってます。