* トラブルはいきなりやって来る
ううう、この日記更新中に、nviが落ちました。しかもコアダンプ(涙) しかもコアダンプ後にttyが道連れになるおまけ付き。しょうがないので、telnetのコマンドモードでcloseして再open。が、日記データの格納されたファイルの長さが0byteになっている!!
…………か、悲しすぎる。すかさず vi -rでリカバリをかけようとするが、リカバリ対象のファイルがないといわれてしまう。しくしく。
* より事態は深刻に
/usr/tmp の中を確認し、編集中の日記データのリカバリファイルらしき物は見つけるが、バイナリファイルのため、そのまま抜き出すわけにはいかない。途方にくれていたとき、よく考えたら、nviを使っていることに気がつき、nvi -rと指示してみる。すると、しっかりファイルは復活したが、日本語部がちゃんと表示されない。実は私の使っている環境には、日本語化されているnviと、そうでないnviがインストールされていて、前者がpath上前にあったのでそちらが起動したらしい。(普段はaliasで起動しているのであんまり意識していなかった)どうせ、EUCを表示できずに16進表示しているだけだろうとかってに思い込み、そのままセーブする。今度は日本語化nviで開くと……。見事に化けたままであった。よくよく見ると、日本語部分はEUCコードではなく、謎の内部コードらしい物
になっていて、1文字あたり3byteと全体的に増えていることが判明。つまり復旧に失敗したことになる。
* あきらめきれずに
普通ならここで断念なのだが、なににせ、朝からちょこちょこ更新していって、バックアップも何もない状態なので、あきらめるにあきらめきれない。で、なんとか内部コードからEUCに変換しようと試みる。まず、日本語化nviのマニュアルを探す。が、見つからない(涙)いっそのことソースを解析しちゃろうかとも思ったが、なににせバイナリインストールしてるので、ソースがない。しょうがないので、hex dumpとって、なんらかの演算をすることでEUC化できないか、考えてみる。ビットを立ててみたり、下4bitを比べてみたり……。うまくいかないのであきらめかけていた時、よくよく見たら、0x8aを前置し、その後にJISコードで2byte
っていう単純な形になっている、ということに遅ればせながら気がつく。内部コードがEUCベースだっていう思い込みが敗因だった(笑)で、すかさず「Hex dumpを読み、0x8aだったら、それを読み飛ばした上で、次の2byteの最上位ビットを立てて出力*2。そうでなければそのまま出力」というperlスクリプトを作成。復旧に成功。ココまで約3時間。(涙)