だいぶ昔に研究した話なのだが、 新情報が入ったので忘れない内にメモメモφ(・・)。
Solaris 2.x の kterm を使って、lynx で日本語を表示させると、 文字コードをきちんと EUC-JP に設定しているにもかかわらず、 全角文字がまったく表示されなくなってしまう。 この原因は terminfo のデフォルト設定のミスである。
また、lynx 以外のソフトでも、同じ原因で文字化けを起こすことがある。
対策は次の通りである。
% infocmp kterm > kterm.info
kterm.info をエディタ等で編集する。
enacs=\E(B\E)0 という部分があるので、これを削除するか、もしくは enacs=\E(B と書き換える。
\E)0というのは、G1（非常に乱暴な言い方をすると、文字コード 0xA0〜0xFF の範囲）に、 プライベートな文字セットの 0 番を割り当てるという意味である。 Solaris のコンソールでは、この文字セットには半角サイズの罫線素片が割り当てられているとのことだが、日本語環境では G1 には全角文字セットが入っていなければならない。 （ちなみに、G1 に全角文字を割り当てることを明示的に指定するには\E$)Bとするのだが、 EUC-JP 以外の環境で実行しても意味がない。）もちろん、残りの
\E(Bというのは、 G0（0x20〜0x7F）を ASCII に戻すという意味。
% sudo tic kterm.info
以上が、Solaris で terminfo をいじる場合の方法である。 Linux でも、よっぽど古いものでない限り同様である。
では、FreeBSD ではどうか。FreeBSD で man 5 terminfo
すると、SEE ALSO の項に tic(1M) があるのだが、実際には
tic コマンドも、infocmp コマンドもない。
実は、FreeBSD の場合は terminfo ではなく、その前身の termcap という仕組みがまだ現役で使われているのである。
tic、infocmpコマンドを含む ncurses ライブラリは base distribution に含まれているのだが、 base distribution ではライブラリだけしかインストールされない。をインストールすればports/ devel/ ncurses tic、infocmpコマンドもインストールされる。
従って、FreeBSD QandA 613 にある通り、
% sudo cap_mkdb /usr/share/misc/termcap
を実行することになる。
友の会のサーバーには、
X 対応でコンパイルした Emacs が入っている。通常なら、このサーバーに
Windows からログインした場合には環境変数 DISPLAY
が設定されていないのでコンソール上で立ち上がるはずなのだが、
私の場合、そうではない。
というのは、たまに Windows 上に X のアプリを呼び出して使うことがある （たとえば、友の会のサーバー上の Netscape を使って、JavaScript 必須のサイトを見に行く場合）ので、TTSSH で、 X の転送を行う設定にしているからである。
この場合、何も考えずに
% emacs
とすると、TTSSH から「localhost:6000 に接続できない」
というエラーが出されて、Emacs が起動せずに終了してしまう。
毎回 emacs -nw とするのは煩わしい（し、setenv
EDITOR='emacs -nw' としても、ツールによっては 'emacs
-nw' という名前の実行ファイルを探しにいってうまくいかない）し、
毎回ログインのたびに unsetenv DISPLAY
するのもやはり煩わしい。
というわけで、こういうことは ~/.login
に書いておくに限る。
if ($?prompt && $?DISPLAY) then
echo -n unsetenv DISPLAY=$DISPLAY '(y/n)?'
set yesno = $<
if ($yesno =~ [yY]* ) then
echo unsetenv DISPLAY
unsetenv DISPLAY
endif
endifここで、$?prompt という変数判定が重要だ。
この判定を怠ると、rcp/scp
でファイルコピーをしようとしたり、rsh / ssh
でコマンドを実行しようとしたときこのコードが反応してしまい、
おかしなことになる。
友の会の環境
（FreeBSD
が、単にソースを展開して、Ports のメンテナーである田岡氏のバグフィックスパッチを当てても、コンパイルが通らない。
そもそも、src/Makefile には /usr/lib/crt0.o
とあるのだが、そんなファイルはない。また、unexecsunos4.o
なるファイルをリンクしようとしている点もあやしい。
ところが、Ports からインストールしようとすると、
これはコンパイルが通るのである。（ただし、依存関係にある
editors/mule-common パッケージが broken ports なので、
いったんバイナリで入れたあとで、
ソースからの再コンパイルをすることになる。）
そこで /usr/ports/ を覗いてみたところ、なんだなんだ、
あるではないか、
以上のまとめはこちらに書いた。
というわけでコンパイルできることはわかったので、
ng を使っていたのだが、
いろいろ不満が出てきた。
まず、改行コードが LF しか対応していない。改行コードが CRLF
のファイルを食わせると、各行末に ^M の表示が出てくる。
また、カーソルキーを押すと無条件でそれに対応するコントロールキーと同一視される。たとえば、[←]を押すと Ctrl-b とみなされるので、
[←]にカーソル移動の機能を割り当てたままで Ctrl-b に
set-mark-command を割り当てる、ということができない。
さらに、Lisp がない（軽さが信条なので、サポート予定もない）ので、 物理行単位でのカーソル移動ができない。
さらに、不正な入力を食わせると落ちるバグもあって、 まだ対処されていない（詳細は 02.08.10 の記述参考）ので、 思い切って Mule を入れることにしたのである。
さて、www.ht には Ports は置いていないので、
必要なファイルは友の会から持ってくる。パッチをあてて、
必要なファイルはコピーして、何事もなくコンパイルは成功。
ハマった点といえば、Makefile で
/var/run/emacs/lock/ を決め打ちしているところである。
ここには書き込めないので、単純にこれを /tmp
に書き換えて、gmake install も成功した。
フルセットを自分のホームディレクトリに置いておく余裕はないので、 Lisp ファイルなどはかなり削った。それでもバイナリ 3MB、Lisp 3MB である。
なお、コンパイル済のパッケージの mule は、
/usr/local/share/mule/19.34/lisp/term/
（このパスはコンパイル時に決定され、事後の変更は不可能）
に所定のファイルがないと動かないので、root
権限がないとインストールはできない。
さて、サーバー入れ替えで Mule が使えなくなってしまった。 エディタがないのは激しく不便なので（もちろん、管理側の立場からするとサーバー上でエディタなぞ使ってほしくないのは百も承知）、 ng を入れることにする。
で、いろいろカスタマイズして、 まあ不満はあるもののひととおり使えるようになったのはいいが、 バグがあることが判明した。
☆
まず、EUC での半角カタカナの取り扱い。 次のようなバグがあることが判明した。
どうやったらそんな不正な入力するの、と言われてしまいそうだが、 私の場合、日本語は Windows 上の ATOK で JIS カナ入力したものを TeraTerm Pro でサーバーに送り込んでおり、「Alt+英字」をタイプすると 「Esc 英字」が送られる設定にしているので、IME を ON にした状態で うっかり Alt+f などと押すと、「Esc ﾊ」と送られてしまうのである。
☆
もうひとつは、 入力ファイル中の不正なバイト列を適切に処理していない問題。
まず、文字コードを EUC に設定したターミナル上で
% perl -e 'print "日本語EUCの文字列\xC0"' > x
として、x というファイルを生成する。内容は
となる。% od -c x 0000000 306 374 313 334 270 354 E U C 244 316 312 270 273 372 316 0000020 363 300
そこで ng でこのファイルを開く。
右カーソルを押し続けていると、「日本語EUCの文字列」
という文字列を越えて、どこまでもカーソルが進んでしまう。
そこで任意の ASCII 文字を入力すると、core を吐いて終了する。
☆
というわけで作者に連絡を取ったところ、手が空き次第確認して対処する、 との連絡をいただいた。
小町くんからは、 「ng を使うくらいなら他のエディタにしたら？」と言われているのだが、 やはりこれが Emacs に近いし、カスタマイズの方法も慣れているので、 当分はこれでいく予定である。
(03.03.03 注) 本日づけで ng 1.4.4 が出ているが、 このバグは修正されていない模様である。
このサイトは SRS さくらインターネット（株）の 「さくらウェブ ライト」というプランを利用しているのだが、 11 月から約款が改定になって、 ライトプランでは CGI を使えなくする方向であるという。 たしかに、サービスの概要というページを見ると、旧来は「30MB まで、CGI/telnet 可」だったのが、「50MB まで、CGI/telnet 不可」に変更になっている。 パーソナルプラン（旧スタンダードプラン）では CGI 可の「タイプ 1」 と CGI 不可の「タイプ 2」とが選択できるようになっている。
その割には、このサーバー（www.ht.sakura.ne.jp） ではディスククォータは 30MB のままだし （というか、少し前までは 100MB と誤設定されていた）、 CGI も問題なく使えているが、いつ設定変更されてもおかしくない。
まあ、CGI なしのプランを設けるという話は分からなくもない。 CGI はウェブサーバーの CPU 資源の多くを喰うから、 CGI が入らなくてもスピードアップしてほしいユーザーにはそういう選択肢があっていいと思う。
しかし、なぜライトプランで CGI ありが選べないのか。 これは私にとっては死活問題である。 私がさくらウェブを選んだのはまさしく自作 CGI と telnet が使えるからであって、これが使えないのでは意味がない。
さいわい、世の中には同じことを考える人が少なからずいるようで、 本日届いたメール（実は、このメールではじめて、ライトプランで CGI/telnet が利用不可になることを知った）によると、
2001/11/1〜 のサービス改定に伴い、 さくら Web サービスライトプランのご利用につきまして、 CGI のご利用を廃止させて頂くべくご案内をさせて頂きましたが、 お客様より CGI のご利用継続のご要望を賜り、 弊社にて再度上記利用について検討させて頂く運びとなりました。とある。アンケート調査を行うというのでさっそく回答した。 CGI は必要、現状のサーバーパフォーマンスには満足 （＝CGI 利用廃止による速度向上は不要）、と回答しておいた。
アンケート結果によっては CGI 廃止の決定が覆る可能性があるが、 下手をすると私はパーソナルプラン（旧スタンダードプラン） へ乗り換えることになり、そうするとまた URL が変わるわけで困る。 …決定が覆ることを祈るのみである。
なお、アンケートには自由記述欄があるので、次のように書いておいた。 3. は、再考を促すためあえて強い口調にしてあるが、 はたしてこれは吉と出るか凶と出るか。
1.
今般の改定は、CGI によるパフォーマンス低下からサーバを解放するのが目的とお察し申し上げますが、私は特にパフォーマンスの低下を実感しません（むしろ、途中の通信回線事情がパフォーマンス上のボトルネックになっているように思います）。ですので、CGI を廃止することによるパフォーマンス上のメリットは私には感じられません。
それでもパフォーマンスが問題になるようならば、 サーバーへの負荷が高いチャットのみを全面禁止し、 掲示板やカウンタなどは旧来どおり認めればいいだけのことです。 ライトプランでは旧来より 「特に転送量が多い場合はライトではなくスタンダード （現パーソナル、ビジネス）を利用させる」 という規定になっているはずですから、 この延長上でチャットのみを禁止すれば済む話であると考えます。 チャットだけの禁止なら、旧来チャットを利用していたユーザーが、 メインコンテンツを現在のサーバーに残したままでチャット場のみを他所へ引っ越すことが容易ですから、 移行上の問題は大きくないと考えます。
そもそも、昨日 23:50 ごろに top コマンドで調べたところ、 CPU パワーは余っているようで、もしパフォーマンスの低下があるとしても、 単純にメモリの増設で解決する問題だと考えます。
2.
私の場合、CGI と telnet が安価に利用できることが御社を利用させていただいている最大の理由です。 ディスク容量が 50MB にアップしたのは喜ぶべきことですが、 CGI 廃止は非常に不満です。ぜひ、ライトプランでもタイプ 1 を選択できるようにしてください。
最悪の場合はパーソナルプランへ移行せざるを得ませんので、 その場合は、おおむね 1 年以上の経過措置をもって、 旧 URL でアクセスしてきたクライアントに対して移行案内が出せるように、 また、引っ越し通知を出さなければいけないので、Referer つきのアクセスログが記録できるようにしていただくことを強く望みます。
3.
御社は有償で我々顧客に対してサービスを提供されているのです。 無償サービスではないのですから、 或るサービスが使えることを前提に旧来契約を結んでいた顧客に対して、 不可抗力でないのに一方的に、かつ相応長期の経過措置も設けずに当該サービスを廃止するのは無責任の極みであり、怒りを覚えます。
御社の責任ある決断をお待ちしております。
（後日注）結局、アンケートの結果は圧倒的多数で CGI 存続希望が優勢で、「現在の利用者に限り、既得権として (?) ライトプランでも CGI を認める」ということになった。 CGI 利用継続申請は郵送でということだったので、 さっそく申し込みをして、受領確認のメールも受け取った。 あとは春のサーバー更新を待つのみである。
大学の旧サイトから「さくらウェブ」へと引っ越した。現在、旧サイトにアクセスしても、
Ausgezogenというメッセージが出るだけになっている。Diese Seite ist in
http://www.ht.sakura.ne.jp/~delmonta/index.htmlausgezogen.
これはどういう仕掛けになっているかというと、旧サイトのほうで
.htaccess に、
RedirectMatchと書いてあるだけであるが、 実はこれにたどりつくまでには色々と紆余曲折があったので、 それをここに書きとめておきたい。（以下、 読者は正規表現を読めるものとして記述するのでご了承いただきたい。また、^/.*l94102(/[^,]*)?$http://user. ecc. u-tokyo. ac. jp/ ~l94102/ temp/ mvd/ ,ausgezogen.cgi $1
.htaccess の書き方については市井の資料にあたられたい。）
まず、最初はリダイレクト先を
「/~l94102//~l94102/ausgezogen.cgi?
ところがこれではうまくいかない。サーバーのエラーログを見てみると、
「ausgezogen.cgiausgezogen.cgi という
CGI に引数として $1 を渡すのではなく、ausgezogen.cgi?/' に変えて、「ausgezogen.cgi/
さて、それで万々歳かというとそうではない。
当初は、次のような設定になっていた。 これのどこがおかしいかお分かりだろうか。
RedirectMatch^/.*l94102(/.*)?$http://user. ecc. u-tokyo. ac. jp/ ~l94102/ temp/ mvd/ ausgezogen.cgi $1
これがどういう挙動を示すか解析してみよう。まず、 ブラウザがサーバーに
をリクエストする。そうすると、サーバーはhttp://user. ecc. u-tokyo. ac. jp /~l94102/ index.html
にアクセスせよという返事を返す。それにアクセスすると、今度はサーバーがhttp://user. ecc. u-tokyo. ac. jp/ ~l94102/ temp/ mvd/ ausgezogen.cgi/ index.html
にアクセスせよという返事を返して、無限ループに陥るのである！http://user. ecc. u-tokyo. ac. jp/ ~l94102/ temp/ mvd/ ausgezogen.cgi/ temp/ mvd/ ausgezogen.cgi/ index.html
そこで、今まで URL に一切コンマは使っていないことを利用し、
ausgezogen.cgi の頭にコンマをつけた上で、
「コンマがあるものは置換の適用除外」としたのが上記の結果なのである。