WSL2のインストールからTIPS迄まとめ

Windows10上に本物のLinux環境を構築できる Windows Subsystem for Linux、略してWSL。現状、初代と vertion 2 の新旧2つが在るが、その新しい方、WSL2について。

WSL2のインストール

手順めんどいのでMicrosoft公式のマニュアルを見よう：Windows Subsystem for Linux (WSL) を Windows 10 にインストールする | Microsoft Docs

将来は、 wsl --install というコマンド一発で出来るようになるみたいだけれど、この記事を執筆している2021年2月2日現在では、まだ Windows Insider Program でのプレビュー状態。人柱上等という人は登録してしまうのも良いかもしれない。

WSLは、あくまで開発者向けのオプションという立ち位置だし、将来的には対応する予定とはいえ、今の所はGUIアプリが動かないので、初心者向けではない気がする。単に「Linux使った事がないから一寸体験してみたい」みたいなケースならば、おそらくVM導入した方が良い。

因みに、現行手順の仮想マシンの機能を有効にした後、Windowsの再起動をサボると、それ以降の手順が上手く行かない。当たり前か。

Linuxのインストール

公式マニュアルにあるが、 Microsoft Store から簡単に入手できる。ディストリビューションに依っては有料の場合も在る事に注意。拘りがないならUbuntuの最新で良い気がする。WSLの大本の Bash on Ubuntu on Windows がUbuntuだし。

パッケージの更新は忘れずに。

# Ubuntu（というかDebian系）の場合
sudo apt update; sudo apt upgrade

Linux（Ubuntu）の日本語環境を整える

少なくとも、Ubuntuの20.04.1はデフォルトでは日本語環境が整っていない。ドキュメントや出力が英語なだけならまだしも、日本語を入力出来ないのは辛すぎる。幸い、表示も入力も日本語に対応させる事が可能なので、その環境を整える。

sudo apt -y install language-pack-ja
sudo update-locale LANG=ja_JP.UTF8
sudo reboot -h now
sudo apt install manpages-ja manpages-ja-dev

これで、一通りWSL2と、その上に構築したLinux（Ubuntu）環境の構築は完了。

WindowsとWSL2上のLinux間での情報のやり取り

Linux側からWindowsのファイルを参照する

/mnt/以下に論理ドライブ毎に、ドライブレターと同じディレクトリ名でマウントされている。例えば、WindowsのC:\はLinux側からは/mnt/c/でアクセスできる。

USBストレージのような、ホットプラグさせる奴はmountする必要が在る。

# ストレージのドライブレターがZで、/mnt/storageにマウントしたい場合：
sudo mkdir /mnt/storage
sudo mount -t drvfs Z:\\ /mnt/storage

Windows側からLinuxのファイルを参照する

\\wsl$\ディストリビューション名\で、Linuxの/（ルートディレクトリ）にアクセスできる。ググると「『C:\Users\ユーザー名\AppData\Local\Packages\ディストリビューション固有のフォルダ\LocalState\rootfs\』でアクセスできる」という情報も引っかかるが、そんな面倒なパスは使わないで良い。

相互にコマンドや実行可能ファイルを実行する

Linux側からWindowsの実行可能ファイルを実行する

実行可能ファイルは、普通に、そのファイルを指定すれば良い。ただし、コマンドプロンプトやPowerShellの用に、拡張子「exe」を省略する事は出来ない。

Windowsの環境変数はLinux側にも渡るので、PATHが通っているのであれば、実行ファイル名（拡張子付き）で実行できる。そうでない場合は、前述の通り/mnt/?で始まるパスで指定すればよい。

引数としてファイルパスを渡す場合、Linux環境上のパスでも、Windows環境上でのパスでも何方でもよい（ただし、Windowsのパスの場合は、エスケープかクォートは必要）。また、Linux側のパスのglob展開も行われる。これは、Linux環境ではglob展開がシェルの仕事であるのに対し、Windows環境では実行ファイルの仕事である為と思われる。結果的に両方のglob展開処理を通る為、双方のファイルパスの表現を認識するという事だろう。

Windows側からLinuxのコマンドを実行する

wsl.exeコマンドを使う。引数で指定した物が実行される。WSLには複数のLinuxディストリビューションがインストール出来るが、デフォルトの物以外を使用したい場合は --distribution（或いは、-d）オプションを使用する。

REM デフォルトのディストリビューションで、 `cat /etc/os-release` を実行する（此処ではUbuntuがデフォルトに設定されているという想定）
wsl cat /etc/os-release

REM Alpine Linux で、 `cat /etc/os-release` を実行する
wsl -d "Alpine" cat /etc/os-release

パスの相互変換

Git for Windows の Git Bash やCygwinに付属しているcygpath相当のwslpathというコマンドがLinux環境側に用意されている。

# Linux環境側のBash

# WindowsのパスをLinuxのパスに変換する。
$ wslpath 'C:\'
/mnt/c/

# LinuxのパスをWindowsのパスに変換する。
$ wslpath -w /home/USERNAME
\\wsl$\Ubuntu\home\USERNAME

Windows側には、同等のコマンドは用意されていないようだ。ただし、前述の通りwslコマンドでLinux側のコマンドが叩けるので、 wsl wslpath /some/path のようにすれば望む結果は得られるだろう。この場合、wslpathは、あくまでLinux用のコマンドである点に注意。Windowsの環境変数は展開されない。

細かいTips

というか注意点。

Windows、Linux間を跨ぐファイルアクセスが遅い

もう吃驚するぐらい遅い。

試しに、同じ環境（Windows環境から同Windows環境のファイルを読む、Linux環境から同Linux環境下のファイルを読む）、別の環境（Windows環境側からLinux環境側のファイルを読む、Linux環境からWindows環境のファイルを読む）のファイルアクセス速度を簡単に調べてみた。本当は何度かやって平均値を取ったり、ファイルサイズの大小での違いとか、ファイルの数に依る違いとか、書き込みの場合はどうかとか調べるべきなのだろうが、そこまではやってない。

実験方法

GitHubに公開されている Windows Terminal のリポジトリ、そのmainブランチの（実験時点での）最新であるコミットハッシュ「a90289548f8548bf5c370a4b141b4b815c22616b」のソースコードのZIPアーカイブをダウンロード。Windows環境とLinux環境側の夫々に展開し、そのディレクトリに対し「terminal」という語を再帰的に検索した。具体的には、夫々で time grep -RF terminal > /dev/null を行った。なお、Windows側での測定には、 Git for Windows 付属の Git Bash 環境を用いた（時間計測の為にtimeコマンドが使いたかった為）。

具体的な実験環境は以下の通り。

マシン

Microsoft Surface Pro 7 （Core-i7、 SSD 16GB、 メモリ 256GB）

Windows環境

Windows10バージョン

20H2

bashバージョン

4.4.23(1)-release (x86_64-pc-msys)

grepバージョン

3.1

Linux環境

ディストリビューション名

Ubuntu

ディストリビューションバージョン

20.04.1 LTS (GNU/Linux 4.19.128-microsoft-standard x86_64)

bashバージョン

5.0.17(1)-release (x86_64-pc-linux-gnu)

grepバージョン

3.4

結果

		検索される環境						別環境÷同環境
		Windows			Linux
		real	user	sys	real	user	sys
検索する環境	Windows	0m0.926s	0m0.124s	0m0.672s	1m39.433s	0m0.421s	0m5.483s	107.379049676
	Linux	0m25.879s	0m0.202s	0m3.947s	0m0.125s	0m0.78s	0m0.039s	207.032

WindowsからLinux管理下のファイルを検索すると100倍遅く、LinuxからWindows管理下のファイルを検索すると200倍遅くなるという結果になった。何処かで読んだ内容に拠ると、夫々のファイルシステムアーキテクチャが全く異なる為、その変換を間に噛ませる必要が在り、それがボトルネックとなるかららしい。インタラクティブなツールの設定ファイルぐらいならば、シンボリックリンクを張って共有しても速度低下は気にならないかもしれないが、基本は夫々の環境で扱うファイルは夫々の環境で処理した方が良さそうだ。

Gitのローカルリポジトリを、クローンした環境以外のGitで操作すると遅い

これは、 WSL というより、純粋にWindowsとLinuxの関係の話となるが、Windows版のGitで作成したりcloneしたリポジトリをLinux側のGitで操作すると、妙に動作が遅い事が有る。具体的には、例えば git status 時に、見慣れない Refresh index: 〜といった出力がなされ、暫く待たされる。

これは 「git forces refresh index after switching between windows and linux - Stack Overflow」 にて解説されているが、Gitがインデックスを再構成している為に生じている。インデックスの構成がOS毎に異なっている為、OSを切り替える度に再構成が必要になってしまうのだ。アクセス出来るからと横着せず、夫々の環境下に別々にcloneし作業するのが妥当だ。