chromebook で開発環境の構築(Crostini と時々Crouton)<br>その① 日本語入力、他L10N

はじめに

crostiniがStable channelでリリースされてから約1ヶ月半、chromebookユーザーにおかれましてはぼちぼちcrostiniとの付き合い方が定まってきた頃ではないでしょうか。

私もここら辺でやったことをまとめておきたいので、以後数回に分けてcrostiniでの開発環境の構築を記録していこうと思います。

なお、Linux知識についてはLPICレベル1学習者(私)程度を想定しています。また環境としては、chromebookはAcer Chromebook 11 CB311-8H、比較対象のcroutonはsudo sh ~/Downloads/crouton -r stretch -t xiwi,e17でインストール済みとします。

今回はGUIでの日本語入力を中心に各種L10Nでやったことをまとめていきます。

ざっくりまとめ

日本語入力

crostini

✔️

できる

crouton

🤔

😂

デスクトップ環境ではできる
(xiwiでアプリケーションのみ起動時はできない)
【追記：1/1】xiwiでもできる！↓

crostini編

とりあえずchromeのインストール

croutonやcrostini上でブラウジングすることはほとんどありませんが、とりあえずフォントの表示や日本語入力の確認のためにchromeをインストールしておきます。また、今後仮想環境上でサーバーを立てる場合などにも動作確認のためにあると便利です。(crostiniとchrome OSのポートマッピングが不安定なため。)

wgetで取ってきてもいいのですが、せっかくデスクトップ環境があるのでchrome OS上で普通にダウンロードしましょう。こちらのページから「CHROME をダウンロード」→「同意してインストール」でdebファイルのダウンロードが始まります。(「64 ビット .deb（Debian/Ubuntu 用）」のラジオボタンがチェックされていることを確認してください。)

ダウンロードが完了すると、「ダウンロード」フォルダ内にgoogle-chrome-stable_current_amd64.debがあるので、それを「Linux ファイル」にドラッグアンドドロップします。(この際、penguinコンテナを起動させておいてください。)

crostiniのターミナルからホームディレクトリで以下コマンドを実行。

sudo apt install ./google-chrome-stable_current_amd64.deb

インストールが完了するとランチャーにLinuxアプリとしてGoogle Chromeが追加されているのが分かります。(アイコンは再起動すると大体反映されます。)

chrome OS側からこのアイコンをクリックするか、crostiniのターミナル上でgoogle-chromeと入力して起動させてみましょう。

適当に初期設定して検索してみるとこんな感じになります。

・・・いわゆるTofu(豆腐)現象ですね。なんらかの情報(IPアドレスとか？)で判断されて日本語ページが表示され、日本語フォントが全てTofuになっています。当然ながら日本語の入力もできません。

notoフォントのインストール

それでは日本語フォントをインストールして再度chromeを開いてみましょう。

sudo apt install fonts-noto

ちなみにnotoフォントは、文字通りこの世からTofuを撲滅するために作られたフォントで、chromebookでもデフォルトで使われています。

Debian -- stretch の fonts-noto パッケージに関する詳細

The name "Noto" is short for "No Tofu", describing the aim of covering all living Unicode scripts (currently 47 are covered, at least partly, across hinted and unhinted).

Tofu (豆腐) is Japanese jargon for unicode replacement character "�" (U+FFFD) often displayed as replacement for unassigned or unknown characters.

Tofuが解消されました！が、依然として日本語入力ができない状態なので、続けて入力メソッドをインストールします。ちょっと調べると最近はFcitxなるものが流行ってるらしいので、まずは先達に倣って試してみます。

日本語入力メソッドのインストール

基本的には、Ubuntu18.04+WSLでfcitx-mozcを使って日本語入力出来るようにする - もやし日誌のパクリです。大変参考になりました、ありがとうございます！

で、詳細は上の記事を見ていただくとして私がやったことをまとめるとこんな感じです。

sudo apt install fcitx-mozc -y && \
echo "export XMODIFIERS=@im=fcitx" >> .bash_aliases && \
source .bash_aliases && \
echo "fcitx-autostart > /dev/null 2&>1 &" >> .profile && \
fcitx-autostart && \
fcitx-configtool

順に見ていくと、まず環境変数を他にもいくつか設定している記事があったりしましたが(以下参照)、crostini上ではXMODIFIERSだけでよさそうです(インストール直後に起動しようとすると、Please set XMODIFIERSというエラーが出ます)。というか、デスクトップ環境をインストールしたLinuxでは環境変数の設定自体不要だったりします(crouton編を参照)。そこらへんはバージョンだったり他のツールだったりディストリビューションなんかで変わってくるんでしょう。

ちなみに、私はなんとなく.bash_aliasesに書いてますが、普通は.bashrcとか.profileに書くのが妥当だと思います。そもそもaliasじゃないし。デフォルトの設定と自分で追加した設定を分けておきたいという意図でこうしてます。ファイル名はなんでもいいのですが、.bashrcを見ると以下の記述があったので怠惰ゆえ流用した次第です。

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

次に、ログイン時にFcitxを起動するようにします。これは一回だけでいいので.profileの方へ。.bashrcとかに書いちゃうとシェルを起動する度に最初のコマンドを実行した後以下のようなメッセージが出て、多分今後tmuxを導入すると地味にうざい。(追記あり↓)

ちなみにfcitx-autostartは以下の短いシェルスクリプトです。

#!/bin/sh

# sleep for a little while to avoid duplicate startup
sleep 2

# Test whether fcitx is running correctly with dbus...
fcitx-remote > /dev/null 2>&1

if [ $? = "1" ]; then
    echo "Fcitx seems is not running"
    fcitx
else
    echo "Fcitx is running correctly."
fi

で、初回のみ手動でfcitx-autostartしてfcitx-configtoolを実行すると設定画面が表示されるので、Mozcを追加すれば完了です。

無事日本語入力ができました！

【追記：1/6】fcitx起動コマンドの記述場所変更

Tmuxを導入して気づいたのですが、Tmuxで新しいウィンドウやペインを作成すると、それらはログインシェルとして振る舞います。(→chromebook で開発環境の構築その③Tmux)

その結果、fcitxの起動コマンドを~/.profileや/etc/profileに記述しても、全てのwindowやpaneで実行されて終了メッセージが出てしまいます。

とても気になる。ということで、いくつかの解決策を検討しました。

サブシェルで隠蔽する(採用)

~/.profileの記述を以下のように変更しました。

(fcitx-autostart > /dev/null 2>&1 &)

丸括弧で括っただけです。こうすることで括弧内のコマンドが別プロセスで実行され、終了メッセージを標準出力(ターミナル)に出さないようにすることができます。サブシェルというらしいです、初めて知った。

参考

というか、1/1追記のxiwiでの日本語入力でも使っているbashコマンドも広義でのサブシェルのようですね。従って上の記述は以下のように書き換え可能です。

bash -c "fcitx-autostart > /dev/null 2>&1 &"

(command)の記法自体初見だったのですが、単にbash -cl commandのシンタックスシュガーみたいなものなのか(ちょっと確認したところ、(command)でのサブシェルはログインシェルのようなので-lオプションを付けてます)、用途に応じて使い分けるべきなのかはまだよく分かってません…。

起動時にcronで`fcitx-autostart`を実行する(失敗・非採用)

crontab -eで以下の記述を追加します。

@reboot fcitx-autostart

で、再起動したところfcitxは起動していてGUIアプリケーションで日本語入力はできるのですが、変換候補のウィンドウが表示されません…。原因不明、非採用。

参考

起動時にsystemd --user でfcitxを実行する(成功・非採用)

「起動時に実行」という目的であればsystemdの方が妥当かと思い調べたところ、以下の記事を発見。

そもそもsystemdのサービス(Unitファイル)を自作できること自体知らなかったので完全に私のレベルを超えてますが、見様見真似でやってみました。

■ systemd --user用のディレクトリ

mkdir -p ~/.config/systemd/user

systemd/ユーザー#基本設定 - ArchWiki

ユーザーサービスは全て ~/.config/systemd/user/ に配置してください。

■ Unitファイル(fcitx.service)の作成

[Unit]
Description=fcitx Autostarting

[Service]
Type=oneshot
ExecStart=/usr/bin/fcitx
RemainAfterExit=yes
EnvironmentFile=/home/username/.config/environment.d/test.conf

[Install]
WantedBy=default.target

最初はEnvironmentFileなしで動かしてみましたが、cronの場合と同様、日本語入力はできても変換ウィンドウが出ないという状態でした。

systemdでは環境変数を持たないらしいので、現在設定されている環境変数のうち明らかに不要な変数以外全て~/.config/environment.d/test.confにぶっこんで参照させるようにしてみたら、無事変換ウィンドウも表示され正常に動作するようになりました。

systemd/ユーザー#環境変数 - ArchWiki

systemd のユーザーインスタンスは .bashrc などに設定された環境変数を全く継承しません。

$HOME ディレクトリが存在するユーザーの場合、~/.config/environment.d/ ディレクトリに NAME=VAL という形式で環境変数を記述した .conf ファイルを作成する。

参考

systemdでユーザーの環境変数を読み込むようにする | bacchi.me

■ サービスを有効にする

systemctl --user enable fcitx

するとおなじみのシンボリックリンクが作成されます。

@🐧:~/.config/systemd$ tree ./
./
└── user
    ├── default.target.wants
    │   └── fcitx.service -> /home/username/.config/systemd/user/fcitx.service
    └── fcitx.service

再起動してみて問題なく動いていることを確認。完了です。

なんだかいっちょ前のLinuxユーザーになった気分ですが、実際のところ全然理解が追いついていないので、とりあえずこのサービスはdisableにしておきます。非採用。

cronでも環境変数を読み込ませる(成功・非採用)

systemdでの成功を受けて、cronでも環境変数を読み込ませればいけるのではと思い調べたら以下の記事を発見。

cronジョブを作るのにいつものやり方でいいんですか? - Qiita

いくつかの方法が紹介されていますが、指定した外部設定ファイルを読み込んでから実行するジョブにする方法でうまくいきました。

■ 環境変数設定ファイルの作成

systemdで作ったファイルを流用しましたが、cronで使う場合にはexport NAME=VALと記述しなければ反映されなかったので、そこだけ変更して~/cron.envとして配置。

■ シェルスクリプトの作成

上記環境変数の設定とfcitx-autostartを実行するシェルスクリプトを作ります。(~/cron_fcitx.sh)

#!/bin/bash

source ~/cron.env
fcitx-autostart

■ cronジョブの追加

@reboot ~/cron_fcitx.sh

再起動すると、ちゃんと変換ウィンドウが表示されました。

ただ、参考記事のコマンド実行前に指定した設定ファイルを読み込んでおく方法などではうまく動かなかった理由はよく分かりません。systemd同様、理解が追いつていませんし、若干力技な感があり非採用。

小括

本筋とは外れたところで追記が長くなってしまいましたが、いくつかの新しい知見が得られました。「起動時に一度だけ実行」という目的であれば、cronよりsystemdの方が自然だと思いますし、今回の例ではcronだとシェルスクリプトを作る必要があったりと手数が多い印象でした。

今回は一時しのぎの方法で対応しましたが、今後systemdの理解を深めてスマートな設定ができるようになりたいと思います。

【追記：ここまで】

そもそも入力メソッドとは？

今までLinuxではそういうのがあるんだと盲目的に受け入れていましたが、今回ちゃんと調べてみました。といってもウィキペディアですが…。

インプットメソッド - Wikipedia: インプットメソッド（英: Input method、IM）とは、コンピュータに文字を入力する為のソフトウェアである。
日本語入力システム - Wikipedia: 日本語入力システムはインプットメソッドのうち、特にパソコンやワープロ、携帯電話などに日本語を入力するためのものを指す。
Google 日本語入力 - Wikipedia: Google 日本語入力（グーグルにほんごにゅうりょく）とは、Googleが開発した日本語入力システム（IME）である。; Mozcとは、Google 日本語入力のオープンソース版である。
オープンソース版のMozcとGoogle 日本語入力との大きな違いは、Mozcは日本語変換エンジンでありこれを用いて日本語入力を行うにはibus、uim、Fcitxのようなインプットメソッドを別途インストールする必要がある点である。
Fcitx - Wikipedia: Fcitx（ファイティクス、[ˈfaɪtɪks]）はUnix系オペレーティングシステム (OS) におけるインプットメソッドフレームワークである。
Debian -- stretch の fcitx-mozc パッケージに関する詳細: fcitx-mozc provides client part of the Mozc input method.

さらにfcitx-mozc パッケージは、以下２つのパッケージに依存しています。(もちろん他にも依存関係はありますがこの文脈で特に重要なもの。)

fcitx-bin | Debian -- stretch の fcitx-bin パッケージに関する詳細: Fcitx は拡張をサポートしている入力メソッドフレームワークで、様々な入力システムを使ってアプリケーションで多様な言葉の文字を入力するインターフェースを提供します。このパッケージは必須となるバイナリ形式の実行ファイルを提供します。
mozc-server | Debian -- stretch の mozc-server パッケージに関する詳細: Mozc は日本語 Input Method Editor (IME) で、Chromium OS, Windows, Mac や Linux などマルチプラットフォームを意図した設計です。mozc-server は Mozc 入力メソッドの GUI ユーティリティを提供します。

まとめると、

「入力メソッド」に該当するのはMozc
Mozcは日本語変換エンジンとしての機能のみ提供する
Fcitx は「入力メソッドフレームワーク」としてインターフェースを提供する

こんな感じでしょうか。いまいちピンときてませんが、とりあえずGoogle 日本語入力コミックを読んで分かったつもりになっておきましょう(変換エンジンは14ページで登場します)。

失敗例

【①：変換候補がTofu】

fcitx-mozcのインストール前後でごちゃごちゃ操作してたら、以下のように変換候補がTofu(utf-16)になってしまいました。再度ごちゃごちゃしたら直りました。再現はできませんでした。原因不明。

【②： im-configはいらない】

FcitxのWikiを見て、わざわざim-configをインストールして設定してみましたがうまくいきませんでした。内容が古いのか、crostiniの独自の環境のせいなのか…。

その他のL10N(Localization)

最近L10Nという言葉を覚えました。

ターミナル日本語化 & 日本語版manpages

manpagesをインストールしていなかったので、ついでに日本語manも入れつつターミナルを日本語化してみます。

■ 使用可能なロケールの確認

$ localectl list-locales
C.UTF-8
en_US.utf8

■ 日本語ロケールのコンパイル

sudo vim /etc/locale.genでja_JP.UTF-8 UTF-8のコメントを外す。または以下実行

sudo sed -ri 's/.*(ja_JP.*UTF-8$)/\1/' /etc/locale.gen

続けて

$ sudo locale-gen
Generating locales (this might take a while)...
  ja_JP.UTF-8... done
  en_US.UTF-8... done
Generation complete.

■ 必要なパッケージのインストール

sudo apt install man-db manpages-dev task-japanese manpages-ja-dev

■ ロケールの設定

sudo localectl set-locale LANG=ja_JP.UTF-8

再起動、またはsource /etc/default/locale

タイムゾーンの設定

■ 現在の設定確認

$ timedatectl
      Local time: 日 2018-12-02 09:09:48 UTC
  Universal time: 日 2018-12-02 09:09:48 UTC
        RTC time: n/a
       Time zone: Etc/UTC (UTC, +0000)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

$ date
2018年 12月  2日 日曜日 09:19:00 UTC

■ 設定

sudo timedatectl set-timezone Asia/Tokyo

■ 確認

$ timedatectl
      Local time: 日 2018-12-02 18:20:09 JST
  Universal time: 日 2018-12-02 09:20:09 UTC
        RTC time: n/a
       Time zone: Asia/Tokyo (JST, +0900)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no

$ date
2018年 12月  2日 日曜日 18:20:14 JST

これで時刻表示やログファイルに記録される時間などもローカライズされるかと思います。SystemdでNPTサーバーと同期するとか、ハードウェアクロックやシステムクロックがどうとかいう情報に惑わされないようにしましょう(自戒)。

crouton編

続いてcroutonも日本語化してみましょう。大体crostiniと同じ手順ですが、とりあえず環境変数などは設定せずにfcitxを起動してみます。

cp Downloads/google-chrome-stable_current_amd64.deb ./ \
&& sudo apt install -y ./google-chrome-stable_current_amd64.deb \
fonts-noto \
fcitx-mozc \
&& fcitx-autostart

すると以下のようなエラーが出ます。

...(略)... X11 not initialized

色々試してみましたが、croutonではデスクトップ環境を立ち上げた状態でなければfcitxを正常に起動させることができませんでした。そのため、xiwiでcrostiniのようにGUIのアプリケーションのみを起動させる場合には、日本語入力はできません。(やり方をご存知であれば是非教えてください！)できます！【1/1】追記参照。

デスクトップ環境Enlightenment(E17)で日本語化

仕方がないのでデスクトップ環境の中で設定してみます。sudo starte17で起動後、「左クリック」→「Settings」→「Language」→「Input Method Settings」と進み、ウィンドウ上で「fcitx」→「OK」とクリックします。再起動後同じ画面まで進み、「Setup Selected Input Method」をクリックするとfcitxの設定画面が出るので、crostiniのときと同じようにMozcを選択すれば完了です。

ターミナルで確認してみると環境変数もちゃんと設定されていることが分かります。

$ env | grep fcitx
ECORE_IMF_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
GTK_IM_MODULE=fcitx

【追記:12/10】頑張ってxiwiでも日本語入力する

起動させたXのプロセスで、デスクトップ環境は立ち上げずに、GUIアプリケーションのみ起動させる方法です。

■ xinitコマンドでXを起動することができます。そのターミナル内でenlightenment_startコマンドを実行すると通常のデスクトップ環境が立ち上がります。

そこで、XのターミナルでfcitxとGUIアプリケーションを実行するようにします。

■ というわけで以下の短いシェルスクリプト(startchrome)を作って適当にパスの通ったディレクトリに配置します。

#!/bin/bash

fcitx-autostart > /dev/null 2>&1
google-chrome

■ xinit startchromeと実行することで日本語入力可能なアプリケーションウィンドウが表示されます。

アプリケーション自体のウィンドウサイズを変えられない(crouton integrationウィンドウ内で黒塗り)し、使う機会はなさそうですが…

【追記：1/1】xiwiでも日本語入力できる！

元日に今年一番の大発見です。コマンドは以下。

xiwi bash -c "fcitx-autostart && google-chrome"

後は適当にaliasを設定しておけばオッケーでしょう！

alias chrome='xiwi bash -c "fcitx-autostart && google-chrome"'

これでcroutonの問題が一つ解消しました。今年はいい一年になりそうです😄🎍

終わりに

以上、crostiniとcroutonでの日本語化(他L10N)をまとめました。

croutonのxiwiでは日本語入力ができないと割り切った上で、今後もcrostiniの比較対象として使っていくことになりそうです。

また、入力メソッドの起動はX Window Systemと深く関わっていることが分かったと同時に、両仮想環境でそれがでどのようにして実装されているのかがとても興味深いです。google Gitのソースが読めるようになりたい…。

承認待ちのコメント 6 年, 4 ヶ月前

承認待ちのコメント 6 年, 3 ヶ月前

承認待ちのコメント 5 年, 9 ヶ月前

承認待ちのコメント 5 年, 8 ヶ月前

承認待ちのコメント 5 年, 4 ヶ月前

承認待ちのコメント 4 年, 7 ヶ月前

承認待ちのコメント 4 年, 4 ヶ月前

承認待ちのコメント 4 年前

承認待ちのコメント 3 年, 11 ヶ月前

承認待ちのコメント 3 年, 10 ヶ月前

承認待ちのコメント 3 年, 9 ヶ月前

承認待ちのコメント 2 年, 11 ヶ月前

新しいコメント

カテゴリー

Java 2

Linux 3

R 1

chromebook 3

docker 1

mezzanine 1

python 1

著者

arakaki (7)

フィード

RSS / Atom

chromebook で開発環境の構築(Crostini と時々Crouton)その① 日本語入力、他L10N arakaki Linux, chromebook 2018-12-02 18 のコメント