FreeBSDマシンにemacs21を導入。Portから入れようとしたのだが、ファイルが見つからないと繰り返すばかりなので、Packageからインストール。ついでにMule-UCSを入れてUTF-8のテキスト処理もできるようにしておく。
.emacs.elの記述は以下のようにした。emacs起動後にUTF-8で保存する場合は、C-x RET f→utf-8を指定。
;;;Basic of Japanese (require 'un-define) (require 'jisx0213) (set-language-environment 'Japanese) (set-default-coding-systems 'euc-jp) (set-terminal-coding-system 'euc-jp) (set-keyboard-coding-system 'euc-jp) (setq default-process-coding-system '(euc-jp . euc-jp))
ついでなのでnavi2ch-emacs21もインストール。日本のLinuxディストリビューションで入っているのをたまに見かけるけど、FreeBSDもPortで用意しているんだね。わはははは。以下のように.emacs.elを書いて、emacs21からM-x navi2chで起動。
;;;for Navi2ch (autoload 'navi2ch "navi2ch" "Navigator for 2ch for Emacs" t)
ただ、どういうわけか起動やスレッドの読み込みなど個々の動作が重い。原因がつかめないようならw3mを使うって手もあるかなぁ。
w3mのインストール。w3mといってもportを見るだけでも何種類か用意されている。昨今UTF-8で記述されたページが多いので、迷うことなくw3m-m17nをインストール。ただ、インストール後に起動したところ、設定ページの内容が英語版だったことが気になった。
たしか、ソースを拾ってきてインストールする場合、configureで日本語版にするか英語版にするかなどを設定する画面が出てくる。ポートの場合それがないので、どこかで設定をしないとならないだろう。んで、w3m-m17nを一度make desintallして、再度make configure。出来上がったworkディレクトリに潜ってconfig.hを開いてみる。ここに「#define LANG EN」とあったのでこれを「#define LANG JA」に変えてみる。ついでに「#define INET6」を「#undef INET6」にして、接続時の動作を軽くする試みをしてみる。これでmakeしてmake installすると確かに日本語の設定画面となった。
ただし、ブックマークの一覧など一部の画面が文字化けする。画面出力をEUCで行っているんだが、日本語の部分が表示されないか「?」マークになってしまうので、文字コードの設定を探さないとならなさそうだ。
ちなみにw3m-m17nからUTF-8で送られてきたページ上の「（￣△￣；」を表示すると「（￣?￣；」という表示になってしまう。少なくともEUC-JP上にある「（￣△￣；」は化けないのだが、「デムパは喋るな」ということか。どうも絡む要素が多すぎて原因もさっぱり。
FreeBSD上でXalan-Jを動かす試み。これが可能なら、FreeBSD上でXSLT変換を行ってそのままアップロードという流れを実現できる。
んで、FreeBSDのJava事情について調べてみたんだが、素敵な状況ではなさそう。FreeBSD 4系列は最近バイナリが配布され始めているらしいが、5系列は対応が追いついていないらしい。
というわけで自前でソースから組み立てるか、LinuxAPI経由でLinux向けのSunのJDKを使うという方法になるらしい。今回は後者の方法にならってPortからlinux-sun-jdk14およびlinux_base-7.1.4をインストール。ちなみにw3mを入れたお陰で、README.htmlを格段に閲覧しやすくなった。
ところが重要な問題があって、javaを起動するとエラーが発生する。
[/usr/local/linux-sun-jdk1.4.2_01/jre/bin]:freebsd>./java -version # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_01-b06 mixed mode) # # Error ID: 4F533F4C494E55580E43505001C9 # Heap at VM Abort: Heap
こんな感じですな。このError IDでググってみるとLinux用のProcが有効になってないから、fstabにprocをマウントしてやれという情報が見つかった。procってUNIXモデルを採用するOSには重要らしく、これが動いていないとファイル処理ができない、と（今の時点では）考えるのがいいのかも。
んで、まずLinux側にfstabを用意。/compat/linuxがLinux側のルートになるようで、そこの/etc/fstab（FreeBSDから見れば/compat/linux/etc/fstab）にprocのマウントを記述。
proc /proc proc rw 0 0
さらに、LinuxAPIでマウントしたprocをFreeBSDでマウントするために「/etc/fstab」に以下の記述を入れる。
linprocfs /compat/linux/proc linprocfs rw 0 0
mount -aで再マウント処理をすれば、Linux用のProcが走り出す。ためしにJavaを走らせてみる。
[/usr/local/linux-sun-jdk1.4.2_01/jre/bin]:freebsd>./java -version java version "1.4.2_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)
問題なし。
Javaが動くようになったところで力尽きたので、本日はXalan-Jのセットアップ。portから入れることも考えたんだが、取り急ぎいろいろ確かめようとMac OS Xで使っていたものをFreeBSD側に転送。「/usr/local/share/java/classes/」以下に「xalan.jar」「xercesImpl.jar」「xml-apis.jar」を配置した。次に「/usr/local/bin/xalan」なる自作のシェルスクリプトを配置。内容はMac OS Xで使っていたものをベースに、ファイルの場所を書き直したもの。
#! /bin/sh
export JAVA_HOME=/usr/local/linux-sun-jdk1.4.2_01/jre
export PATH=$PATH:/usr/local/linux-sun-jdk1.4.2_01/jre/bin
XALAN_HOME=/usr/local/share/java/classes
export XALAN_HOME
CLASSPATH=${CLASSPATH}:$XALAN_HOME/xalan.jar
CLASSPATH=${CLASSPATH}:$XALAN_HOME/xercesImpl.jar
CLASSPATH=${CLASSPATH}:$XALAN_HOME/xml-apis.jar
java org.apache.xalan.xslt.Process -in $2 -xsl $1 -out $3
これで、シェルスクリプトを走らせると見事に変換成功！苦労したかいがあった。
w3mのブックマーク画面での文字化け問題。あれこれ設定を見回してみたら、簡単に答えが見つかった。「文字コードの設定」から文書の標準の文字コードの設定を「EUC-JP」に変更するだけだ。おいらの場合デフォルトでUTF-8になっていたのだが、他の環境でもこれが標準なのだろうか？
Navi2chの起動や動作が遅い問題、どうやらEmacs21のパフォーマンスの問題に関連している模様。人によってはWonderTrastでも遅くなるらしい。とは言え何をどう改善すればいいのかなど、度素人のおいらにはわかるわけでもなく、また速度を求めてEmacs20にするというのも何だ。ゆっくり情報を探そう。
デスクトップで使っているLinuxに入っているモジラのバージョンを1.1系列から1.2系列に挙げようと、このマシンでは初めてのapt-getを試みる。ところが依存関係の確認に入ったところで処理が止まってしまう。
topコマンドでの確認では、apt-getのSTATはD。つまり止まっているも同然の状態。なんか情報はないかと/var/log/messageを開くと、DMAのタイムアウトが記録されていた。つまり、DMA転送でこけてしまっているみたい。
DMAをオフにする方法を探したんだが、/sbin/hdparmというコマンドで調整が可能なようだ。とりあえず、/sbin/hdparm -d 0 -c 0 /dev/hdaでDMAをオフにして、再度apt-get。今度はスムーズに入った。
このhdparmはベンチマークの可能なようで、-tオプションを指定してDMAオン／オフ時の書き込みを比べてみたが、オンの時がだいだい6.9MB/sec、オフの時が2.25MB/sec。-iオプションからわかる情報によると、デフォルトではmdma2というのが指定されているけど、これを切った状態で起動する方法がわからない。とりあえず、問題が起きたらその都度DMAを切る方向で対応するつもり。
FreeBSDマシンには、ノートマシンからログインすることが多いんだけど、makeに時間のかかるportを入れている最中に、寝る時間になってしまいノートを閉じたいといった事態が出てくる。作業中に接続を切ってしまうと何がどうなるのかわからないので、できればログアウト後もセッションだけは残しておきたい。
というわけでscreenを入れてみようと考えた。いまいち使い方のわかりにくいソフトのような気もするんだけど、しっかり覚えないと。
screen自体は端末上で複数のコンソールを実現するソフトなんだけど、タブ切り替えの可能な端末と次のような点で異なると認識している。
まず、コンピュータのスリープなんかと同様に現在の状況をセッションとして保持したまま接続を終了できる。つまり通常のタブ付き端末は、スリープ機能のないコンピュータみたいなもので、使い終わったらシステムを終了してすべての作業を終了させないとならない。で、Screnの場合はいろんなソフトの作業状態を確保したまんまスリープという形でマシンを休止できる。
コンソールの切り替えやセッションの休止などの操作はすべてキーコンビネーションになるので覚えるのは大変そうだけど、なれれば便利になりそう。というわけで、/usr/port/misc/screenからインストール。
では実際に使用を。screenで起動すると一瞬説明が表示されて、「Space」キーを押すとシェルに戻る。そして例えばEmacsで適当な書類を開いてみる。この状態から、C-a C-dを押すと、[detached]と表示してシェルに戻る。これでログアウト。
再ログイン後、psコマンドでscreenのプロセスIDを探す。そしてscreen -r [プロセスID]を実行して復帰するといった次第。
FreeBSDのportに入っているScreenはC-aをキーにしていろんな操作ができるらしい。例えば、Screenの終了はC-a C-/、新規のコンソールはC-a C-c、コンソールの一覧はC-a C-wといった具合。