蝉は、やがて死ぬる午後に気づいた。ああ、私たち、もっと仕合せになってよかったのだ。:2009年11月03日分

2009/11/03(Tue)

[OpenBSD] Q: is the OpenBSD supports UTF-8 locale? A: No!

@

昨日のネタの続き、mutt開発者でOpenBSDユーザの tamoさん
uimコミッタでOpenBSDユーザの いわたさんからの情報で事情掴めました。
いつもいつもありがとうございます。

結論、gtk+なアプリならGTK_IM_MODULE経由だとOSのlocaleサポートなしでも動いちゃったりするみたい。
そういやあれGNU libiconvリンクしてるからなぁ、それにしても

(process:16313): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.

とか警告出すのにぜんぜんCにfallbackしてないじゃねーか、おい。

つまり、件の記事はさも

  • ja_JP.UTF-8 localeが有効
  • ximも動く

ような事が書いてあったのだけどそれはジャン=ルイ・ガセーネタで
GTK_IM_MODULEだけしか動かないちゅーことです、であるならば.xinitrcのサンプルは
余計な警告を出すだけのLANG環境変数とどうせ動かないuim-ximの行は削っちまって

GTK_IM_MODULE=uim; export GTK_IM_MODULE
uim-toolbar-gtk &
exec twm

でおkっちゅうこと、一部のアプリが動いとるだけで「日本語入力システムが利用可能」とは言わんがな。
なんで、ここまで読んだ人はmisc@あたりに「xtermに入力できません」とか突撃するなよ!(ダチョウ倶楽部的な意味で)

一部のアプリが動けばいいのなら、私が常々自虐ジョークネタとして使ってる
「*BSDにはlinux emulationがあるので国際化されてるアプリが使いたければlinux binary使え」
でOKということなんだよな(半分本気)。

それにしてもGTK_IM_MODULEってアレだよな、libcannaとかlibwnnを直接リンクしてた時代に逆戻りとしか思えん。
まぁXIMがあくまでX環境のものであってdirectfbみたいにframebuffer環境だと必要ってのはわかるけど。

あとfallbackしてないの話に戻るけど、正直GTK+が内部UTF-8で動こうがどうでもいいんだけど
ちゃんと外側についてはcurrent localeの文字エンコーディングを尊重してんだろうかね。
複数の文字エンコーディングを同時に扱うって、セキュリティの原則としてあんまり宜しくないんですが。

@

(追記)
pkg_add firefox35したらuimで入力できてワロタ。
ただしlocaleはCなので、jaのデフォルト変換エンジンであるAnthyは有効になってないので
ツールボックスから選択してやる必要があるけど。

んで、繰り返しますがlocaleはCなので、あの お馬鹿なfontconfigにも悩まされず、きれいな欧文フォントで表示されるので
むしろNetBSDでもLANG=Cで起動した方が(ぉ

今日

@

このチラシの裏でも何度かネタ( 1

2

3

)にしたレヴィ=ストロース先生死去、R.I.P

個人的にはやぱし 野生の思考がおぬぬめ。

バブル時代は構造主義を知ってる俺クールというナンパの道具だったらしいぞ。