Luminescence

先日 sufary から sary に移行した辞書検索システムなのだけど、何の気なしに使っていて、妙な問題に直面している。

インデックスを使っているので、辞書だけで優に 100 M bytes を超える辞書ファイルもタイムラグを気にすることなく使える……のだけど、どういうことなのか、"thin" という単語だけ、ひいても出て来ずにインデックス検索が刺さる（そこで立ち往生する）のである。何故こんなことに？

単語の頭文字のせいなのだろうか、と考え、"thick" をひいてみると、ちゃんと瞬時に辞書の記述が表示される。他の色々な単語で試してみても、どういうわけか "thin" だけひけないのである。辞書ファイルの破損でもあったのか、と思い grep してみたが、"thin" に対応する記述はちゃんと存在している。

まあ普段は thin なんて単語をひくことはまずない（だって……分かりますよね、thin の意味位）のだけど、ふとしたときにこんな現象を発見してしまうと、どうも落ち着かない。英辞郎の最新版である第五版を購入して試してみようか、いやしかしそろそろ第六版出るかもしれないしなあ……と思案に暮れる今日この頃なのであった。

【後記】結局英辞郎の第五版を購入した。届き次第新しい辞書を作成する予定。

sdic で英辞郎の辞書検索に用いているインデックス・ユーティリティを sufary から sary に移行した。以下メモ。

sary は Debian GNU/Linux のパッケージに入っているので、apt-get 等でインストールすればよろしい。インデックス作成は、

$ mksary -c UTF-8 eijirou.sdic

Emacs 側の設定を抜き書きしておく。

;;;
;;; sdic
;;;
(autoload 'sdic-describe-word "sdic" "search word" t nil)
(global-set-key "\C-cw" 'sdic-describe-word)
(autoload 'sdic-describe-word-at-point "sdic" "カーソル位置の英単語の意味を調べる" t nil)
(global-set-key "\C-cW" 'sdic-describe-word-at-point)

;; ----- sdicが呼ばれたときの設定
(eval-after-load "sdic"
  '(progn
     ;; saryのコマンドをセットする
     (setq sdicf-array-command "/usr/bin/sary")
     ;; sdicファイルのある位置を設定し、arrayコマンドを使用するよう設定(現在のところ英和のみ)
     (setq sdic-eiwa-dictionary-list
           '((sdicf-client "/usr/local/share/dict/eijirou.sdic"
                           (strategy array)))
           sdic-waei-dictionary-list
           '((sdicf-client "/usr/local/share/dict/waeijirou.sdic"
                           (strategy array))))
     ;; saryを直接使用できるように sdicf.el 内に定義されているarrayコマンド用関数を強制的に置換
     (fset 'sdicf-array-init 'sdicf-common-init)
     (fset 'sdicf-array-quit 'sdicf-common-quit)
     (fset 'sdicf-array-search
           (lambda (sdic pattern &optional case regexp)
             (sdicf-array-init sdic)
             (if regexp
                 (signal 'sdicf-invalid-method '(regexp))
               (save-excursion
                 (set-buffer (sdicf-get-buffer sdic))
                 (delete-region (point-min) (point-max))
                 (apply 'sdicf-call-process
                        sdicf-array-command
                        (sdicf-get-coding-system sdic)
                        nil t nil
                        (if case
                            (list "-i" pattern (sdicf-get-filename sdic))
                          (list pattern (sdicf-get-filename sdic))))
                 (goto-char (point-min))
                 (let (entries)
                   (while (not (eobp)) (sdicf-search-internal))
                   (nreverse entries))))))
     ;; おまけ--辞書バッファ内で移動した時、常にバッファの一行目になるようにする
     (defadvice sdic-forward-item (after sdic-forward-item-always-top activate)
       (recenter 0))
     (defadvice sdic-backward-item (after sdic-backward-item-always-top activate)
       (recenter 0))))

(setq sdic-default-coding-system 'utf-8-unix)

U から、メールで受けたテキストファイルが Mac 上で読めない、と聞かされる。どれどれ……あー、はいはい。

僕が Internet を使い始めて20年が経過したわけだが、その当初から、この日本語の問題は存在していた。当時は、いわゆるパソコン上では Shift_JIS と呼ばれる文字コード（正確には Microsoft CP932 と言うべきなのだろうけど）、UNIX 系のコンピュータ上では EUC-JP や JIS が使われていた。Shift_JIS は、文字コードの一部がいわゆるエスケープシーケンスとカブることや、半角カナの問題などがあるために、僕の周囲のほとんどの人が EUC 党か JIS 党（僕はこっちである）に分かれ、各々がその文字コードで自らのシステムを統一的に構築していた。

こうした状態が一気に変わっていったのは、前世紀末からの Unicode の台頭であった。Microsoft も、Windows 2000 以降の OS を Unicode で国際化したし、今はもはやメンテされていない Kondara MNU/Linux などが先駆けとなって、Linux / UNIX の世界も急激に UTF-8 化が進行した。現在は、日本語の文字コードが大きく分けて4つ存在する、という「異常事態」であるわけだけど、基本的には流れは Unicode に収斂しつつあるのかなあ、という感じだ。

さて。今回の U の問題だけど、どうもこの文書は JIS らしい。Mac OS X 上においては、基本的には日本語の文字コードは Unicode を使っている。表向きは Shift_JIS を使っているように見える（し、実際使える）のだけれど、これは backward compatibility のため、という色彩が濃い。いずれにしても、文字コードを Unicode に変換しなければならない。U が今後作業することを考えて、MultiTextConverterを入れることにした。これはドラッグ & ドロップでテキストファイルの文字コードを簡単に変換することができる。

ただし、U の Mac 上での日本語変換の環境は、実はもうとっくに整えてあった。先の MacPorts から homebrew への入れ替え時にもメンテナンスをしたけれど、それとは関係なく最大前提としてiconvは入っているし、このメンテのときにはnkfも更新してある。こういったフィルタとしての日本語コード変換ソフトは、シェルのパイプラインを分かっている人にとっては何の気負いもなく使われているものなのだけど、まあ確かに普通の人には使いにくいものかもしれない。

僕は歴史的な経緯からQKCがお気に入りなのだけど、現在使用する上で致命的なのが、Unicode を扱えないということだ。これに関しては、Sugano `Koshian' Yoshihisa氏が書かれたnkc（ruby スクリプトである）を使わせてもらっている。僕の個人端末には、legacy な qkc もちゃんと入っているのだけど、個人用以外のコンピュータ上では、nkf か、せいぜい nkc 位までを入れておくことにしている。

僕は実は Mac OS X も使っている。U の仕事用の Mac の管理のため、ということなのだけど、いくら Mac OS X が UNIX だといっても、そのままではちょっと CUI で管理を行う上で不便なことも多いので、いわゆるデベロッパーズキットみたいなものを入れているわけだ。

Mac OS X を UNIX として使用する場合は、まず Xcode と XQuartz を入れることになる。これまでは、これに加えて MacPorts でいくつかのパッケージを入れて使用していたわけだが、MacPorts の場合は、基本的に Mac OS X 付属のユーティリティとは独立に各ユーティリティを入れるので、たとえば Perl や Ruby は2重化されることになる。これはこれでまあ怪しげなところがなくっていいのだけど、丁度 Windows における Cygwin のような感じで、母体になる OS の上で浮いた存在になっているとも言える。Cygwin の場合はまあそれでいいのだろうけれど、UNIX のユーティリティの中に更に UNIX のユーティリティが浮いている、というのは、どうも落ち着きがよろしくない。

そんなことを感じつつも MacPorts を使っていたのだが、最近になってhomebrewなる存在を知った。これは先に書いた大物ユーティリティの重複が生じないような構成になっているらしい。まあ、U の Mac はディスクが巨大なので、ちょっとやそっとの重複などヘでもないのだが、折角なので、この機会に homebrew に移行しておくことにする。

まずは、MacPorts の解説 "2.5. Uninstall (Chapter 2. Installing MacPorts)"を見ながら MacPorts を削除する。この際に特に注意しなければならないのは、MacPorts で導入した shell を login shell にしていた場合は、事前に /bin/bash などに chsh しておかないとエラいことになる、ということ（具体的には login できなくなる……まあ当然だけど）。Mac OS X が Ubuntu などと同様に su できない仕様になっているとはいえ、こういう事態を招いたときのために、コンサバティブな管理方針の管理用アカウントをひとつ用意しておくと安全なのだろう。

削除が終わったら、homebrew のインストールガイドに従って：

ruby -e "$(curl -fsSLk https://gist.github.com/raw/323731/install_homebrew.rb)"

brew install package

brew update