WSL2でmikutterを動かす

WSL2すごいですね。みなさん使っていますか？僕は使っています。

WSL2 + Docker + VSCodeの環境ならWeb開発もあまり不自由なくできそう……ということで思い切ってメインマシンをWindowsにしたんですが、この環境の弱点の一つとして、令和三種の神器のひとつであるmikutterの動かし方があまり明らかではないという問題があります。WSL1でmikutterを動かすことについてはすでに id:cobodo さんによる記事があるんですが、WSL2だとネットワークが分離されているようで追加の設定が必要になっています。せっかくなので2020年7月現在の正解として、他の部分も含めてまとめておきます。

cobodoさんの記事はこれです。 cobodo.hateblo.jp

mikutterと必要なものを入れる

WSL2の身上は高速なディスクアクセスです。ゲストはホストを無視してLinuxのファイルシステムに書き込むので、普通にLinuxを使っているかのような速度でI/Oしてくれます。mikutterもちゃんと ~/mikutter とかに入れてあげましょう。

$ cd ~
$ git clone git://mikutter.hachune.net/mikutter.git

まっさらなUbuntu（この記事では全面的にUbuntuを仮定します）にはあんまり開発に便利なものが入っておらず、一部gemのnative extensionを入れるときにコケるので入れます。あと依存ライブラリとフォントも入れます。不思議な旅をしたい人は 開発環境部分については bundle install の出力とにらめっこしながら1つずつ解消していってもいいと思いますが、フォントは闇なのでおとなしく先人の知恵を借りたほうがいいと思います。

$ sudo apt update
$ sudo apt install gcc make ruby libgtk2.0-dev libidn11-dev fonts-noto fonts-noto-cjk fonts-noto-mono ttf-ancient-fonts
$ sudo gem install bundler
$ bundle install --path=vendor

たぶん今からWSL2を始める人がUbuntuを入れると20.04が降ってくるんですが、Rubyはなんと2.7.0p0が入ります。Ubuntuで最新リリースが使えるなんて夢みたいですね（2020/7/4現在）。あと上記コマンドでは面倒なので bundler をグローバルに入れています。どうせ仮想環境だし……。気になる人は rbenv 使ったり GEM_HOME いじったりして頑張ってください。僕は大丈夫です。

X serverを立てる

VcXsrvを使ってWindows上にX serverを立てます。どうでもいいけどSourceforgeの見た目がきれいになっててびっくりしました。

sourceforge.net

WSL1ではWSL環境がWindowsと同一ホスト上で動いていたらしく DISPLAY=:0.0 を指定するだけでVcXsrvに繋げたようなのですが、WSL2ではネットワークが分離されたため、普通に繋ごうとするとWindowsのファイアウォールが邪魔をしてきます。"WSL2 Xorg"とかでぐぐると以下のStack Overflowが出てきます。

stackoverflow.com

要点は

  1. VcXsrv起動時に"Disable access control"をチェックしておく
  2. VcXsrvのpublic domain上でのBlock ruleを無効化する（これがあると他のルールを無視して問答無用でブロックされるため）
  3. Public domain上でInboundのTCP 6000を開ける（環境によっては6000-6063を全部開けたほうがいいかも？）
  4. DISPLAY 環境変数に接続先IPを指定する

の4点です。

2と3はWindows Defender Firewallのルールです。タスクバーの便利ボックスにWindows Defender Firewallとか入れると出てきます。Block rule無効化のやつはDisable access controlを忘れてWindows Defenderにファイアウォールを設定してもらうと作られる設定っぽいので、存在しないなら存在しないでよいです。Windows Defender Firewallでは以下のようにルールが見えます。Allowルールは緑のチェック、Blockルールは赤の止まれ、無効化されてるルールは無のアイコンが表示されます。

f:id:osa_k:20200704174330p:plain

TCP 6000はX serverが待ち受けてるポートです。WSL2上で見えるIPはプライベートIPなのになんでPublic domainをいじる必要があるのかWindows初心者なのでいまいち分かってないですが、とりあえずこれで動きます。

今回はTCP 6000を開けるためにこんなルールを作りましたが、VcXsrvがこのポートで通信できればなんでもいいです。

f:id:osa_k:20200704165348p:plain f:id:osa_k:20200704165410p:plain f:id:osa_k:20200704165419p:plain

上記SOからリンクされてるwsl-windows-toolbar-launcherのREADMEも情報としておすすめです。 github.com

DISPLAY 環境変数に入れるIPアドレスは /etc/resolve.conf を見ると書いてあります。と上記SOに書いてあります。 ~/.profile に以下の設定を書いとくとよいと思います。

export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0

SOの回答には export LIBGL_ALWAYS_INDIRECT=1 も書いてあるんですが、これが何をするのかよく分からないのと、mikutterに関してはなくても動いてるので無視してます。OpenGLを使うタイプのアプリケーションだと影響してくるのかな。

IMを入れる

WSLはunixソケットに対応していなくてdbusが使えない……という情報がインターネットで散見されますが、最近は使えるっぽいです。使えるのはうれしいので fcitx-mozc を入れましょう。以下の記事がよくまとまっていますが、情報が古いためか不要な操作がそこそこ挟まっているようです。2020/7/4現在では本記事の通りにやればうまく動くはずです。

kazblog.hateblo.jp

$ sudo apt install fcitx-mozc dbus-x11
$ fcitx-autostart

無事に起動したら fcitx-config-gtk3 からIMを設定して完了です。注意点なのですが、fcitx-autostart は DISPLAY 環境変数が正しく設定されてない場合、正常終了したように見せかけて無の fcitx を起動してきます。この状態で fcitx-config-gtk3 を起動するとdbusに繋げないよーみたいなログが端末に出てくるのと、IM一覧が空っぽになるので分かります。そうなってしまったら pkill fcitx して再チャレンジしましょう。 fcitx-autostart は謎が多く、エラーメッセージっぽいものが出ていても動作に支障がないことも多々あります。究極的には実際に日本語入力できるかどうかで判断するしかないと思います。

XやGTKやQtにIMを使ってもらうには環境変数を適切に設定する必要があります。~/.profile とかに書いときましょう。

export XMODIFIERS=@im=fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx

mikutterを使う

念のため新しいWSLシェルを開いて実行すると環境変数の設定漏れとかが防げておすすめです。fcitxのデフォルトではCtrl + SpaceでIM切り替えです。

$ cd ~/mikutter
$ bundle exec ruby mikutter.rb

𝕎𝕖𝕝𝕔𝕠𝕞𝕖 𝕥𝕠 𝕦𝕟𝕕𝕖𝕣𝕘𝕣𝕠𝕦𝕟𝕕...