debian stretch時代のtmux事情(East Asian Width問題)
debian stretch時代のtmux事情(East Asian Width問題)
TL;DR
- tmux 2.2以降になった。(stretch以降)
- custom charmapを置くことでαや─├などが全角扱いされるよ!(昔から)
- tmuxで表示が崩れなくったヤッター(stretch以降)
East Asian Widthとは
Unicodeにおける全角と半角に相当する概念を取り扱ったものです。UAX #11: East Asian Width が詳しいです。この中にAmbiguous(以後A文字と記す)という文脈によって文字幅が異なる文字が規定されています。実際どの文字がA文字に該当するかはhttp://ftp.unicode.org/Public/UNIDATA/EastAsianWidth.txt を参照してください。
この中でA文字としてαなどのギリシャ文字や─などの罫線素片が含まれています。
とくにこの罫線素片がA文字に含まれていることがターミナルユーザーには大きな問題が起こっていました。
libcと文字幅判定
POSIXの中にはwcwidthあるいはwcswidthと言うワイド文字(列)を表示幅をはんていするAPIが存在します。ncursesなどのCUIを提供するライブラリが各文字の幅を参照する場合もこのAPIから情報を取得していたりします。Debianにて標準的に使われているglibc実装ではwcwidthが参照する情報は/usr/share/i18n/charmap以下にあるファイルに記述されていて、UTF-8の場合は全てUTF-8.gzを参照しています。
はい、欧米・東アジアロケール関係なくUTF-8のlocaleはコレを参照してます。
このファイルの生成は上記のEastAsianWidth.txtからスクリプトで生成されているらしいです。
このA文字の扱いを全角扱いにするcharmapを公開されている方が居られました。感謝
tmuxの場合(tmux 2.2未満まで)
上記のcharmapで解決するのはwcwidthに基づいて文字幅を判定している物のみです。
2.2未満のtmuxがこの例外に当てはまり、かつてのtmuxではutf8フラグ存在していました(2.5現在は無い筈)。このフラグをONにするとペイン間の分割がUnicodeの罫線素片を使用するようになったり、tmux内部にハードコーディングされた判定処理を用いて文字幅を判定したりするようになっておりました。
この判定処理にはA文字の取り扱いを行う特別な対応などは存在せず、すべて半角扱いされていました。tmux 2.2では文字幅の判定はwcwidthなどの外部ライブラリを参照するようなりました。
debian stretchのtmux事情
リリースされたdebian stretchではtmux 2.3が採用されており上記の問題は解決しました!Yatta!
DN2820FYK:Intel純正の安心感に翻弄されたはなし
DN2820FYKは私が大学を出て会社員として働き始めた2013年に発売されました。
大学近くから引っ越しタイミングでML115G5を捨てて自宅サーバーを家では買わないと考えていました。
当時の私の考えを変えたのが、当時の部署の先輩でした。
先輩「お家にサーバー無いとかmjd!?」
私 「大学時代は持ってたんですけど、煩いですし電気代もかかりますし」
先輩「最近NUCみたいな小型の省電力PCがあるんだYo! しかもAtom SoC(BayTrail-M)の奴が今度出るしそれならもっと省電力だよ、NUCとしても安いしどうよ?」
当時のIntel NUC DN2820FYKのスペックのサイトを見せながら勧誘してくる先輩にホイホイ連れられてその日は帰りに秋葉原に直行したのだった。
たしかBuymoreかTsukumoで買った記憶がある。
当時のNUCはちょっと電源ケーブルが付属しないという問題があり、ミッ●ーマウス(IEC C5-NEMA 5-15)ケーブルを別途購入しておかないといけなかったのだ。
DN2820FYK世代あたりでユニバーサルなプラグ一式が付いたACアダプタになってそのような問題もなくなりました。
自宅でセットアップしようとして
自宅に持ち帰りセットアップをしようとしてBIOS画面を覗いていた時でした。
「あたらしくセットアップするならUEFIだよねー」
「Debian Wheezyあたりを入れるからどちらでもいいんだが……」
「そもそもなんでこんな選択肢があるんだ?とりあえずWindows 8にしておこう」
「USBメモリにイメージをddして挿せばインストールできるだろ」
Intel 純正の安心感に遭遇
むむむ、DN2820FYKH linux3.12では普通に進むのに、linux3.13では死ぬとかこれは如何に?
— まきひろ (@m_akihiro) 2014年3月30日
Intel NUCはUEFI bootさせる場合はUEFI Shell v2のbcfgコマンドでbootオーダー設定しないと行けないエラー。 APCI周りでSystem Description Tables取れねえと電源制御が死んだりしてる
— まきひろ (@m_akihiro) 2014年3月23日
色々とハマりましたがたしかLinux3.12で動かして回避する策をとったはずです。
会社の先輩はCentOS6を入れて普通に使えてたそうな
数か月後に出たファームウェアにアップデートしたら当時のDebianのwheezy-backportsにあるカーネルでも動いてたと思います。
Intel様は2016年現在でもDN2820FYK用のファーム更新を出してるいい会社ですよ?
DN2820FYK自体はkimchiによるKVMの母艦サーバー(お家でKVMするならこれくらいが一番良かった)やDockerホスト、踏み台用openbsdサーバーなど紆余曲折を経て現在はMinecraftのマルチプレイ用サーバとして活躍中です。
このDN2820FYKを購入してからお家サーバーの数も増え、DN2820FYKとNUC5i3RYB、minATX筐体の自作ファイルサーバー兼録画サーバー兼エンコードサーバー(ECCメモリを使ってないという致命的な欠点があるので組み替え予定)とRPiな温度センサなどが賑わう様になりました。