Windows 10の次期大型アップデートとなるRS4(RedStoen 4: 開発コード名)では、WSL(Windows Subsystem for Linux)とWindows 10の相互運用性が大きく高まるようだ。
執筆時点のWindows 10 Insider Previewの最新ビルド17074.1002だが、2017年12月にリリースしたビルド17063から、新たな環境変数「WSLENV」が加わった。同時期に公式ブログで、これに関する概要が明らかとなったがなかなか興味深い。
WSLENVは、Windows 10のコマンドプロンプト/Windows PowerShellからWSLプロセスを起動、もしくはその逆の操作を行う際に参照し、「C:\Users\kaz」を「/mnt/c/Users/kaz」へ変換、もしくはその逆変換を実現するものだ。
環境変数は、CUIからコマンドを実行する際の設定やOS上でデータを共有する際に用いられてきた。有名どころを挙げれば、コマンド検索を行う環境変数「PATH」だろう。
例えばWindows 10でコマンドプロンプトを起動し、Robocopy.exeを実行するとしよう。ユーザー権限でコマンドプロンプトを起動するとカレントディレクトリ(フォルダ)は環境変数「USERPROFILE」で定義したフォルダとなるが、%SystemRoot%\System32\Robocopy.exeを起動するにはフルパスで記述しなければならない。このパスを省略して実行できるのは、PATHの値に%SystemRoot%\System32フォルダーを含んでいるからだ。
WSLENVのメリットはどこにある?
さて、WSLENVのメリットを考えたい。WSLENVには環境変数を引き継ぐ際にパスを変換するフラグ「/p」、区切り文字を用いたパスを変換して引き継ぐ「/l」、コマンドプロンプトからWSLへ環境変数を引き継ぐ「/u」とパスの変換を行う「/up」、WSLからコマンドプロンプトへ環境変数を引き継ぐ「/w」の5つが用意されている。
上図はMicrosoftの説明に沿ってWSLの動作を検証したものだが、ご覧のとおりフラグ「/p」などを使えば、デスクトップへのパスが自動的に変換されるため、バッチファイルやシェルスクリプトを実行する際にパスの扱い方を意識する必要がなくなる。
また、必要に応じてフラグ「/u」もしくは「/w」を使えば、Windows 10もしくはWSL固有の情報をもう一方へ引き継げるため、両者の差異をそれほど意識しなくともよい。
公式ブログではVisual Studio Codeで開発言語Goのプロジェクトファイルを書いて、ビルドを可能にする例を紹介し、「VSCodeとの統合が可能になる」と述べている。今回は試していないが、vimの設定ファイルである「~/.vimrc(_vimrc)」をWindows版とLinux版で共通運用するなど、多様な利用方法が可能になるだろう。
RS4上のWSLはこの他にもchmod/chownによる所有権の設定やWindowsネイティブのtarやcurlを用意し、バックグラウンドタスクやプロセス間通信ソケットのサポート機能が加わる予定だ。
今回の環境変数WSLENV自体は小さな改良ながらも、Windows 10とWSLをシームレスにつなぎ、相互運用性を高めつつある。もちろんネイティブのLinux環境と比べるといくつかの互換性問題があるものの、WSLを初実装したWindows 10 Anniversary Updateの頃を振り返れば、順調な成長を遂げてきた。
今後は開発者じゃなくともWSLを利用した処理の自動化など、利用シーンが大きく広がるはずだ。RS4は2018年3月のリリースを予定している。
阿久津良和(Cactus)