Windows上のBashシェル入門【Windows 10 Fall Creators Update対応】（1）
Windows Subsystem for Linuxとは？ そのインストールと使い方
Fall Creators Updateで正式版として提供されることになった「Windows 10上で動作するLinuxサブシステム」によるBashシェルの基礎を理解・マスターすることをゴールとして、Windows Subsystem for Linux（WSL、旧称：Bash on Ubuntu on Windows）の概要から、インストール方法までを解説。また、よくある疑問をQ＆A形式で短くまとめる。
“Windows Subsystem for Linux”（以下、WSL）は、2016年4月の発表当時から「WindowsにBashシェルが入る！」と大きな話題となり、それ以来、注目を集めてきた。図1はそのWSLによるUbuntu（Linux）のBashシェルを実行した例だ（※このBashシェルについて以前は、“Bash on Ubuntu on Windows”／“Bash on Windows”という名前でも呼ばれていたが、現在、この名前は非推奨となっているので注意してほしい）。
このWSLの最新アップデート版が搭載されたWindows 10が春と秋に毎年リリースされている。これまで、以下のメジャーバージョンアップの歴史がある。
- 2016年8月2日： Windows 10 Anniversary Update［初期バージョン］
- 2017年4月5日： Windows 10 Creators Update［1回目の更新］*1
- 2017年10月17日： Windows 10 Fall Creators Update［2回目の更新］*1【今回の対象】
執筆時点で最新版のWindows 10 Fall Creators Updateの更新プログラム（手動インストール用）が2017年10月17日（日本時間では18日）に公開された。Windows Updateによる一般提供は、10月17日以降、順次、行われる予定となっている。
- *1 更新プログラムの名前に「Fall」が付くか付かないかの違いで間違えやすいので注意してほしい。
このBashシェル搭載は、特にWeb開発者やPython／Rubyなどの開発者らにとって大歓迎されているのではないだろうか。最近では、ノウハウや情報が豊富なBashシェルで作業するケースが多くなってきている。そんなBash環境利用のために、本当は使い慣れたWindowsを使いたくても、仕方なくMacやLinuxを使っていたという人も少なくないだろう。そういう人にとっては、このWSLがWindows回帰に役立つ可能性がある。
では、WSLでどんなことができるのだろうか？ 本稿ではまず、「WSLがWindowsにおいてどんな位置づけのものなのか」といった特徴や背景、内部構成の概要、WSLが動作する仕組みを紹介し、次に、一般的によくあるWSLに関する疑問をQ＆A形式で簡潔にまとめる。さらに本稿後半では、WSLのインストールから、基本的な環境準備までを一通り説明する。本稿を読めば、WSLの基礎が最短・最速で学べるようになっている。
＜目次＞
- Windowsの新サブシステム「Windows Subsystem for Linux」とは
- Windows Subsystem for Linuxに関するQ＆A
- Q： PowerShellはどうなるの？ Windowsの管理もBash？
- Q： 運用サーバーとして使える？
- Q： Windows Server 2016でも利用できるの？
- Q： 動かないものがあった場合はどうすればいいの？
- Q： Ubuntu／SUSE Linux Enterprise Server／OpenSUSEで動いているパッケージを使いたいけど、再コンパイルが必要？
- Q： どんなLinuxソフトでも動くの？
- Q： Bash内からWindowsソフト（.exeファイル）も実行できるの？
- Q： Windows内からBash上のコマンドを実行する方法
- Q： Windowsのログオンユーザーが使えるの？
- Q： 日本語ファイル名が使えるの？
- Q： 空白を含むファイル名は使えるの？
- Q： Windowsってパス名260文字までだから、長いファイル名が使えないのでは？
- Q： どこにインストールされているの？
- Q： セキュリティ
- Q： 複数のLinuxディストリビューションをインストールした場合の起動方法
- Q： 既定のLinuxディストリビューションを変更する方法
- Windows Subsystem for Linuxのインストール
- Ubuntuパッケージの導入
すでにWSLを試したことがあり、今回のFall Creators Updateでは、主に開発者モードが不要や、bash.exeからwsl.exeへのコマンド変更などの機能が行われており、いずれの機能も本稿の中で簡単に紹介している。
Windowsの新サブシステム「Windows Subsystem for Linux」とは
WSL登場以前のWindowsの*nix環境
WindowsでLinuxのツールを使う方法は、WSLが登場するまでにもいくつか用意されていた。
- Hyper-V／VMware／VirtualBoxといった仮想化環境を使ってLinuxを実行する
- Git for Windows
- Cygwin
- MinGW
- MSYS2
このうち仮想化環境では、マシンリソースの消費やホストOSとのファイルのやりとりをシームレスに行えないという問題があった。
また、Cygwinをはじめとするエミュレーション環境では、シームレスなやりとりはできるものの、Windowsとツール類を共存させた場合に、同名のコマンドが意図せず呼び出されてしまう、という問題があった。例えば、findというコマンドはLinuxにもWindowsにも用意されている。しかし、両者の引数および、コマンドの仕様は異なっており、同じように呼び出すことはできない。例えば環境変数PATHに対して（Windowsのパスよりも）先にCygwinのパスが定義されていた場合、Windowsのfindコマンドを呼び出そうとしてもCygwin側のコマンドが呼び出されてしまい、意図どおりの正確なコマンド実行ができないといった問題が発生する。
かつてのWindowsには、POSIXやOS/2といったサブシステムが提供されており、それぞれのサブシステムに準拠したアプリケーションを実行することができた（POSIXは再コンパイルが必要、OS/2は16bit版のコマンドラインアプリケーションがそのまま実行できた）。しかし、これらのサブシステムは様々な理由からWindows XPで廃止された。UNIX環境との相互運用を目的としてServices for UNIX、Subsystem for UNIX-based Applicationsといったサブシステムが用意され、その上で動作するアプリーション（＝UNIXで提供されているツールを、POSIXサブシステムを使って移植したもの）が提供されていた。しかし、提供当時のニーズやマイクロソフトにおける製品戦略などが徐々に変化してきたためと思われるが、だんだんと収束し、現在では提供されていない。
これら従来のUNIX／Linuxツール使用環境に対し、最新Windows 10のWSLは、Linuxのツール（＝厳密にはLinuxディストリビューションのUbuntu、SUSE Linux Enterprise Server（以下、SLES）、OpenSUSE上で動作可能なツール）をWindows上でそのまま使えるようにするために、仮想化環境でもエミュレーション環境でもコンテナーでもない、新しいサブシステムとして導入されたのだ。実利用において厳密なWSLの内部仕様を理解する必要はあまりないと思われるが、参考知識として、新サブシステムの内容と、WSL（によるBashシェル）が動作する仕組みを簡単に示しておこう。
「Windows上のLinux開発ツールセット」を支える新サブシステム“WSL”
現在のWindowsはもともと、マイクロカーネルに、複数のサブシステムが共存できるアーキテクチャだ。WindowsのGUIはWindowsサブシステムというサブシステムで動いているし、前述のとおり、かつてはPOSIXやOS/2といったサブシステムが提供されていた。
2016年8月のWindows 10 Anniversary Updateで、Linuxツールのために新しく作られたサブシステムが、冒頭から登場しているWindows Subsystem for Linux（WSL）である。WSLはPOSIXやOS/2サブシステムとは異なり、Linux互換環境を提供するlxss.sysとlxcore.sysという2つのカーネルドライバーで実装されている（※ちなみに「LX」は「Linux」を意味する省略語）。WSLでは、これら2つを合わせてPicoプロバイダードライバーと呼んでいる。
WSLの仕組みについて本格的に説明すると文章がかなり長くなってしまうので、以下ではWSLの大まかな概要のみを簡単に示す。WSLは、図2に示すような複数のコンポーネント群で構成されている。前述のlxss.sysとlxcore.sysは、この図ではLXSSとLXCoreというコンポーネントとして表現されている。この図の内容・意味については次節で説明する。
「Windows Subsystem for Linux Overview – Windows Subsystem for Linux」から「Figure 1: WSL Components」の図を引用（※画像は独自に拡張して再作成）。
WSLが動作する仕組み
※2017/10/30修正： 本節の内容に誤りがありました。お詫びして訂正させていただきます。修正箇所が多いため、変更前の記載は削除済みです。修正後の記載は下線付きで表されています。図2も以下の説明に合わせて修正しました。
WSLによりLinuxディストリビューションが実行できるわけだが、その仕組みや処理の流れは前掲の図2で示されているので、ここではその図の内容を一通り説明しよう。
図2を見ると、ユーザーモード（＝通常のアプリケーションとして動作するもの）内に各ディストリビューション起動用のアプリケーション（Ubuntuであればubuntu.exeなど）があるのに気付くだろう。このアプリケーションから、WSLのランチャーであるwsl.exeが起動され、ターミナル（＝コンソールウィンドウ）が表示される。そのターミナル上でユーザーが入力したコマンドを受け付けてLinuxディストリビューション（Ubuntuなど）のBashシェルに渡し、またBashシェルの出力をユーザーに表示する。当然ながらBashシェルの本体は、Linuxインスタンス（WSL）上にある/bin/bashの方である。
wsl.exeにより処理が実行開始されると、黒色の矢印で示されている COM の流れでWin32プロセスであるLXセッション・マネージャー・サービス（LX Session manager service）が仲介して、緑色矢印の ioctl の流れでカーネルモード（＝Windowsカーネル側）で動作するPicoプロバイダードライバーがその処理を実現する形となっている。また、紫色矢印の Bus の流れで、Windows上で動くLinuxインスタンス（Ubuntu）が生成（init）・管理され、さらに青色矢印の fork の流れで、Linuxインスタンス（Ubuntu）上の/bin/bashがPicoプロセス（＝LinuxプログラムをWindows OS上でそのまま実行できるプロセス）として生成（fork）される。
また、WSL利用時に/bin/bash上で処理が実行されると、赤色矢印の syscall の流れで、Linuxのシステムコール（＝WindowsでいうAPIのようなもの）が発行され、それをPicoプロバイダードライバーが処理する。Picoプロバイダードライバー内部では、システムコールをフックして、Windowsに相当するAPIがある場合はWindows APIで処理を行い、Windows APIに存在しないシステムコールはLinuxカーネルが（つまりWSL内部だけで）処理する形になる。
なぜWSLが必要だったのか
ところで、なぜWSLが提供されるようになったのだろうか？ あくまでも筆者の想像だが、「オープンソース化の推進」と「クロスプラットフォームの推進」が大きな要因だったのではないかと考えている。
以前から多くのプロダクトがオープンソースで提供されていたが、2014年以降は、特に企業が開発ツールやライブラリをオープンソースとして提供する例がさらに多くなってきた。そしてそれらはLinuxやMacを前提としているものが多く、Windowsは対応されたとしても後から、という状況もしばしば見られた。
前述のように、UNIX互換環境や仮想化環境で使うという方法もあるが、再コンパイルや、システムリソースの問題、前述したようなWindowsとの共存の問題も発生するため、「WindowsにLinux互換のサブシステムを作って動かせばいいのではないか」という発想になったのではないかと考えている。
2011年にMS Researchが『DrawBridge』という論文で「Windows以外のシステムを実行する軽量なサブシステム」を実現する仕組みを発表している。このDrawBridgeがWSLの原型になったと考えられる。
以上、WSLの特徴や仕組み、登場の背景を説明した。とはいっても、「WindowsでBashが動く」ということについて、依然としてさまざまな疑問が残っているのではないだろうか。インストールや使用方法の説明に入る前に、前提知識として、特によくある疑問をQ＆A形式で簡単にまとめておこう。
Windows Subsystem for Linuxに関するQ＆A
Q： PowerShellはどうなるの？ Windowsの管理もBash？
A： WSLはあくまでも開発ツールセットの一つとして提供されている。現時点において、Windowsの管理はあくまでもPowerShellやコマンドプロンプトで行う。
ちなみに2016年8月19日、PowerShellが.NET Coreを使用したオープンソースとして公開された。恐らく、マイクロソフトが提供するクロスプラットフォーム向けのツールでは、そのオープンソース版のPowerShellが活用されていくことになるだろう。
Q： 運用サーバーとして使える？
A： サポートの問題から使用できない。
現在のWSLでは、nginxやMySQLといった、サーバー機能のアプリケーションを実行することは不可能ではないものの、仕様上の制限によりサポートされない。具体的には、現在のWindows ServerのWSLではデーモン（daemon）を実行できないので、例えばLinux用のMySQLをWSLで使うというシナリオはサポートされていない。
以下のブログでも「現在のWSLではLinuxサービス、デーモン、ジョブなどのバックグラウンドタスクは動作しない」と言及されている。
Just as with WSL on Windows Client, you can run daemons and jobs like MySQL, PostgreSQL, sshd, etc., via an interactive shell, but you cannot currently use WSL to run persistent Linux services, daemons, jobs, etc. as background tasks.
Q： Windows Server 2016でも利用できるの？
A： 半期チャネル（英語では“Semi-Annual channel”）*2でリリースされるWindows Server（Version 1709）により、Windows ServerでもWSLがサポートされた。2017年4月のCreators Updateまでは「サーバー製品ではサポートしない」という方針だったが、「開発者向け、システム管理者向けにLinuxを管理する機能が必要である」ということで方針が変更された。
Why include WSL on Windows Server?
We want Windows, including Windows Server, to be a great place for developers. We know developers, system administrators, people managing services and people building services all occasionally need tools available on Linux. Many more would like to run Linux tools as part of their workflow as a matter of convenience
- *2 半期チャネルは現在のWindows Serverのリリースモデルで、年に2回、春と秋に新しいリリースが公開される。ちなみに、従来の「長期10年サポート」型のリリースモデルはLong Term Servicingチャネルという呼び方になっている。参考：「Windows Server の半期チャネルの概要」。
Q： 動かないものがあった場合はどうすればいいの？
A： 機能上のバグに関してはGitHubのissue、アイデアに関してはUserVoiceに、いずれも英語で書いてほしい。UserVoiceに投票する前に、既存のアイデアがないか、まずキーワードで検索して、似たアイデアがあった場合、そのアイデアに［Vote］ボタンを押して投票しよう。Voteの数が投票数となっており、Vote数が多いアイデアに関しては、開発チームにおいて優先的に実装する目安となっている。
投票数には上限が設定されているが、開発チームが開発終了などの理由でクローズしたアイデアに関してはVoteした数がユーザーに戻され、別のアイデアに投票できる。Voteおよびアイデアを投稿する際にはGoogleアカウントかFacebookアカウントが必要になる。
Q： Ubuntu／SUSE Linux Enterprise Server／OpenSUSEで動いているパッケージを使いたいけど、再コンパイルが必要？
A： Ubuntu／SLES／OpenSUSEといった各ディストリビューションのELF64バイナリがそのままWindows上で実行されるため、再コンパイルは不要だ。例えばUbuntuの場合、CanonicalのサーバーからUbuntuの64bit版パッケージを取得しているし、非公式なリポジトリ（PPA：Personal Package Archive）を指定しても問題ない。もちろん、非公式リポジトリを使用する場合、提供元ベンダーおよび、サーバーが信頼できるかどうかの判断は使用者に委ねられる。
Q： どんなLinuxソフトでも動くの？
A： 各ディストリビューションから提供されている全てのパッケージが動作するわけではない。WSLに実装されているシステムコールの範囲で動作するため、実際にパッケージをインストールしないと、動くかどうかは分からない。例えば執筆時点において、標準パッケージに含まれるコマンドでもshutdownのように実行できないコマンドがある。
（繰り返しになるが）WSLは開発ツールセットの一つとして開発されているため、開発ツールセットおよび、サービスに必要なシステムコールの実装が優先されているようだ。
Q： Bash内からWindowsソフト（.exeファイル）も実行できるの？
A： 2017年4月のCreators Updateの新機能で、WindowsとWSLのコマンドの相互運用が強化された。これにより、WSLからWindowsプログラムを呼び出せるようになった。Bashを起動すると、Windowsに登録されている環境変数PATHが自動的にWSL側にも反映されるため、Windowsプログラムを呼び出すことも可能だ（※なお、拡張子の.exeを含めて呼び出す必要があるので、例えばファイル内からテキストを検索するためのコマンドの名前はfind.exeとなり、Linuxが提供している同名で別機能のfindコマンドが意図せず呼び出される問題も起きない）。また逆に、WindowsからBash上のLinuxアプリケーションを呼び出して、WSLの標準出力をWindows側でキャプチャすることもできるようになった。具体的な方法に関しては「Bash on Ubuntu on Windowsの、Creators Updateでの強化点＆新機能」および1つ下のQで説明しているので、そちらを参照してほしい。
Q： Windows内からBash上のコマンドを実行する方法
※2017/10/30追記： 本節の内容を追記しました。
A： Windowsのターミナル（PowerShellやコマンドプロンプト）上でwsl.exe（＝wslコマンド）を呼び出すことで、既定（デフォルト）のLinuxディストリビューションにおけるBashシェル上のコマンド（プログラム）を実行することが可能だ。wslコマンドの引数に、WSLのプログラムを引数付きで指定する。例えばリスト1は、Windowsのdirコマンドにより、現在のディレクトリに含まれるファイル＆ディレクトリの名前一覧を出力し、パイプ（|）によりその一覧を入力として後続のコマンドに流している。後続にあるWindowsのwslコマンドにより、そのコマンドライン引数に指定されたgrep txtという引数付きのBash上プログラムが実行される。ちなみに、このプログラムは「txt」にマッチする行をフィルターして出力する。
|
dir | wsl grep txt
|
なお、Windowsのターミナル上でwslコマンドを引数なしで起動した場合は、Windowsのsystem32フォルダーがカレントになった状態で、Bashシェルのセッションが開始される（ちなみにシェルセッションを終了するにはexitコマンドを実行する）。WSLにおける既定のLinuxディストリビューションのホームディレクトリをカレントにしたい場合は、wsl ~と~を引数に指定すればよい（リスト2）。
|
wsl ~
|
Q： Windowsのログオンユーザーが使えるの？
A： WindowsのログオンユーザーとWSLのユーザーは無関係に管理される。ディストリビューションインストール時にディストリビューション用のユーザーを作成する。
Q： 日本語ファイル名が使えるの？
A：コンソールで日本語の使用は可能だが、WSLで提供されているコマンドが日本語ファイル名を扱えるかどうかは、各ディストリビューションで提供されているパッケージで日本語ファイル名が扱えるかどうか、という点に依存する。
Q： 空白を含むファイル名は使えるの？
A： こちらも日本語ファイル名と同様、WSLで使用するコマンドに依存する。しかし、LinuxをはじめとするUNIX系ではあまり空白をファイル名として使用しないため、Windowsで作られた空白を含むファイル名をWSLに渡さない方がよい。
Q： Windowsってパス名260文字までだから、長いファイル名が使えないのでは？
A： もともとWindowsが標準で使用しているNTFSというファイルシステムでは、最大64KB（UTF-16で3万2767文字）までのパス名をサポートしており、Win32のUnicodeアプリケーションであれば長いパス名を使用できた（※本稿でいう「パス名」とは、ドライブ名やフォルダー名、ファイル名を\で連結して並べたもののこと）。しかし、Windows 95系列との互換性のため、ほとんどのアプリケーションが260文字を上限にしている。.NET Frameworkでも、バージョン4.6.1までは、もしくはAnniversary Update以降をインストールしていないWindows 10では、260文字が上限となる。
WSLではNTFSの上限までの長さのパス名が使用できる。
Q： どこにインストールされているの？
A： ストアからインストールした場合、C:\Program Files\WindowsAppsフォルダーにインストールされている（※標準ではCドライブになるが、図3の手順で［設定］アプリを使って他のドライブに変更することも可能だ＝2017/10/26修正）。
Creators Update以前のWindowsからアップグレードした場合は、%LocalAppData%\lxssフォルダーのままだ。
これらのフォルダーはWindowsのログオンユーザーごとに管理されているため、複数のユーザーでWSLを使用する場合、ユーザーごとにWSLやUbuntuパッケージのインストールが必要になる。
なお、WSL開発チームはこれらのフォルダーの内容をWindowsのツールで操作することは意図していない（参考：「チームブログ：Do not change Linux files using Windows apps and tools（英語）」）。そもそもストアからインストールした場合のC:\Program Files\WindowsAppsフォルダーは、ユーザーによって操作できない仕様である。
【注意事項】ストアアプリのインストール先を変更している場合
ストアアプリの場合、図3の手順で［設定］アプリを使って他のドライブに変更することが可能だが、Fall Creators UpdateのWSLではサポートされていない（※2017/10/26追記： 初稿時に「WSLでもできる」と記載していましたが誤りでした。お詫びして訂正させていただきます。参考「チームブログ：New distros coming to Bash/WSL via Windows Store（英語）」）。
Q： セキュリティ
A： 不正な通信を遮断するためにはWindowsの［セキュリティが強化された Windows ファイアウォール］で行う（※ウィンドウを起動するにはwf.mscコマンドを実行）。ファイアウォールはWindowsと共有するため、WSL側でiptablesなどを設定する必要はない。WSL側で使用しているポートにアクセスできないといった場合は、まずはWindowsのファイアウォール設定を見直してほしい。
WSL固有の注意点として、SSH（Secure Shell）サービスがWindowsで実行されており、既定では全てのネットワークで外部からの通信を受け入れる設定になっている。WSLにSSHでログインする必要がなければ［セキュリティが強化された Windows ファイアウォール］でSSH Server Proxy Serviceを無効にした後、［コンピューターの管理］（compmgmt.mscコマンドで起動）でSSH Server BrokerとSSH Server Proxyを停止する。コマンドで行う場合、「管理者として実行」したPowerShellからリスト3のコマンドレットを実行して、ファイアウォールルールの無効化および、サービスを停止すればよい。
ただし、第2回で紹介している、Visual Studioを使用した、リモートデバッグ時にはsshサービスが必要になるので、リモート開発を行う場合は無効にしてはならない。
|
Disable-NetFirewallRule -Name "SshProxy-Service"
Stop-Service -name SshProxy
Stop-Service -name SshBroker
|
Q： 複数のLinuxディストリビューションをインストールした場合の起動方法
※2017/10/30修正： 本節の内容に誤りがありました。お詫びして訂正させていただきます。修正箇所が多いため、変更前の記載は削除済みです。修正後の記載は下線付きで表されています。
A： 2017年10月のFall Creators Updateから、ストア経由でインストールできるようになった。また、複数のLinuxディストリビューションが共存できるようになっている。
複数のうち任意のディストリビューションを起動する場合、［スタート］メニューから起動するときは、目的のショートカットを実行するだけである。では、コマンドで起動する場合はどうすればいいのだろうか？
最も簡単なのは、system32フォルダーにあるwsl.exeを実行することだ。ディストリビューションが1つだけインストールされている場合、そのディストリビューションが起動される。
複数のディストリビューションがインストールされている場合は、インストールした順番で最初のディストリビューションが起動される。例えば、Ubuntu→OpenSUSEの順番でインストールしていた場合はUbuntuが起動する。仮に、Ubuntuをアンインストールした場合、OpenSUSEが起動するようになる。仮に、再度Ubuntuをインストールし直しても、やはり順番どおりにOpenSUSEが起動する。
では、特定のディストリビューションを起動したい場合はどうすればいいだろうか？ Ubuntuの場合はubuntu.exe、SLESの場合はSLES-12.exe、OpenSUSEの場合はopenSUSE-42.exeというコマンドで起動可能である。
ちょっと変わった方法として、各ディストリビューションはストアからダウンロードしているので、UWPアプリケーションをコマンドラインから起動する方法と同じTIPSが使用可能だ。具体的にはリスト4のようにStart-Processコマンドレットを実行すれば、PowerShellから特定のディストリビューション（この例ではUbuntu）が起動できる。Start-Processコマンドレットの引数として指定するappxパッケージ名（PackageFamilyName）やアプリケーションID（Application.Id）は、PowerShellのGet-AppxPackageコマンドレットで調査できる。リスト4ではUbuntuを調査しているが、SLESの場合はUbuntuをSUSELinuxEnterpriseServerに変更、OpneSUSEの場合はUbuntuをOpenSUSEに変更すればよい。
|
PS> (Get-AppxPackage -name *Ubuntu*).PackageFamilyName
CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc
PS> (Get-AppxPackage -name *Ubuntu* | Get-AppxPackageManifest).Package.Applications.Application.Id
ubuntu
PS> Start-Process shell:AppsFolder\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc!ubuntu
|
Q： 既定のLinuxディストリビューションを変更する方法
※2017/10/30追記： 本節の内容を追記しました。
複数のLinuxディストリビューションをインストールしている環境で、既定のディストリビューションを明示的に変更したい場合は、wslconfig.exe（wslconfigコマンド）を使用すればよい（参考：「Manage multiple Linux Distributions in WSL（英語）」）。コマンドの内容は図4を参考にしてほしい。
Windows Subsystem for Linuxのインストール
さて、WSLに関する必要十分な基礎知識が備わったところで、ここからは実践編としてWSLのインストールや使用方法の説明に入ろう。なお、すでにインストール済みで使用中の方はアップデート方法の説明までスキップしてほしい。
WSLを使用するには、事前に64bit版のAnniversary Update以降のWindows 10をインストールしている必要がある（つまりWindows 10を最新版にアップデートすればよい）。Anniversary Update以降をインストールしていれば、WSLは64bit版のWindows 10のHome／Professional／Enterpriseの全エディションで使用できる。
【コラム】開発者モードが不要になったWSL
2017年4月のCreators Updateまでは「開発者専用のツール」という位置づけだったため、Windowsを開発者モードに変更しなくては使えない仕様だったWSLだが、Fall Creators Updateから開発者モードへの変更は不要になり、誰でも使えるようになった。開発者以外にもWSLが有効だというフィードバックが多くあったためのようだ。
WSLのインストール
管理者モードでPowerShellウィンドウを起動し、以下のコマンドレットを実行する（※コマンド実行中に再起動を要求されるので、Windows 10を再起動する）。
|
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
|
Linuxディストリビューションのインストール
再起動後、［スタート］メニューから［ストア］を実行して、インストールしたいディストリビューションを選択し、[購入]をクリックしてインストールする（図5）。2017年10月のFall Creators Updateリリース時点では「Ubuntu」「OpenSUSE」「SUSE Linux Enterprise Server」の3種類が使用可能だ（※「Ubuntu」や「SUSE」で検索するとよい）。
［購入］ボタン（もしくは［入手］ボタン）をクリックすれば、インストールが開始される（※表記は「購入」だが、無償なので、クレジットカード決済などは発生しない）。
ストアからのインストール完了後、パッケージの展開が行われる。しばらく待った後、Linuxのユーザー名とパスワードを聞かれるので（図6）、それぞれ入力してアカウントを作成すれば、WSLが使用可能な状態になる。
【ヒント】日本語環境でWSLを使用したい場合
2017年10月のFall Creators UpdateでWSLが正式版となったことで、マイクロソフトのサポートが受けられるようになった。注意点として、ストアからインストールするディストリビューションは英語環境のままなので、日本語ロケールが必要になる場合は、明示的に設定する必要がある。もっとも、日本語フォントはインストールされているので、日本語ファイル名を表示、作成するだけなら問題ない。
英語ロケールで問題になるのはlsコマンドでの日付表記やアプリケーションが出力するメッセージが英語になる、といったところだ。update-locale LANG=ja_JP.UTF8コマンドで日本語ロケールに変更すればよい。下記リンク先は英語版に切り替える方法を説明した記事だが、日本語に切り替えるときにはja_JPを指定すればよい。
【ヒント】WSLが正常にインストール完了しない場合
WSLのインストールが完了しない場合は、セキュリティソフトが影響している可能性がある（特にカスペルスキーとWSLは相性が悪いようだ）。その場合には、いったんセキュリティソフトを終了してみてほしい。これで解決する場合がある。
【ヒント】Linuxディストリビューションのアンインストールと、WSLの再構築
インストール済みのLinuxディストリビューションをいったんアンインストールして、再度、インストールし直すことで、Linux環境をゼロから再構築したい場合もあるだろう。
2017年10月のFall Creators Updateからストア経由でLinuxディストリビューションをインストールできるようになったため、各ディストリビューションのアンインストールは簡単だ。図7のように［スタート］メニューから対象のショートカット項目（この例では［Ubuntu］）を表示し、その右クリックメニューから［アンインストール］を選択すれば削除される。
ちなみに、2017年4月のCreators UpdateまでのWindows 10では、管理者として起動したPowerShellもしくはコマンドプロンプトで下記のコマンドを順に実行すれば、Linux環境を再構築できた。
- （1）WSLをアンインストール：
lxrun /uninstall /full - （2）WSLを再インストール：
lxrun /install
ただし、2017年10月のFall Creators Update以降のWSLでlxrunコマンドを起動すると、図8のように「レガシーなコンポーネント」という扱いになっており、最新環境でlxrunコマンドを使うのはお勧めできないので注意してほしい。
以上でWSLとLinuxディストリビューション環境の準備は完了だ。これでBashシェルが使用可能になっている。
［旧バージョンをインストール済みの方のみ］Windows Subsystem for Linuxのアップデート
Windows 10を古いバージョンから新しいバージョンに（例えばCreators UpdateからFall Creators Updateに）アップデートしても、WSLでインストール済みのUbuntuなどのLinuxディストリビューションは最新版に更新されない。しかも各ディストリビューションの標準アップグレード方法はサポートされていないため、上記の「【ヒント】Linuxディストリビューションのアンインストールと、WSLの再構築」を参考に、一度、対象のディストリビューションをアンインストールした後で、ストアから再インストールする必要がある（参考： 「WSL adds Ubuntu 16.04 Xenial support（英語）」）。
もちろん、アンインストール用のコマンドを実行するとUbuntuのホームディレクトリに格納しているファイルも消えるため、SSHの秘密鍵などのUbuntuにしかないファイルは事前にバックアップしておく必要がある。ただし前述したとおり、エクスプローラーをはじめとするWindowsのツールでUbuntuのフォルダーの操作を行ってはならないため、UbuntuのターミナルからWindowsのフォルダーに対象ファイルをコピーして、Windowsのツールを使用してバックアップの採取を行う必要がある。
Linuxディストリビューションの起動
次回以降各ディストリビューションを起動する場合は、すでに説明したように、［スタート］メニューに登録されている各ディストリビューションのショートカット（図9では［Ubuntu］、他には［SUSE Linux Enterprise Server 12］／［OpenSUSE Leap 42］など）をクリックして実行する。
［Ubuntu］をクリック
Ubuntuパッケージの導入
基本的な方法
WSLで実行されているディストリビューションはそれぞれのディストリビューションそのものなので、パッケージのインストール／更新／削除は各ディストリビューションの方法に従ってほしい。本連載ではUbuntuを例にとって紹介する。
Ubuntuの場合、apt-getコマンドで実行可能だ。apt-getの使い方は、「公式ページ：AptGet/Howto（英語）」を参照してほしい。本稿ではapt-getコマンドの代わりにaptコマンドを使っているが、使い方はほぼ同じである（※Ubuntu 16.04からはaptコマンドの利用が推奨されている）。
ただし、全てのパッケージがWSLで動作可能ではない。サポートしているシステムコールによっては動かないものがあるのだ。
だからといってすぐに諦めないでほしい。昨日は動かなくても、最新のInsider Previewでは動作可能になっている場合があるからだ。例えば、2017年4月のCreators Updateではサポートされるシステムコールが増えたため、Node.jsやHaskellといったソフトウェアが実行可能になった。
代表的なパッケージのインストール方法を簡単に紹介してこう。ちなみに以下でPythonのインストール方法を省略している理由は、Ubuntu 16.04からPython 3が標準でインストールされているからである。
Git
Gitは公式パッケージとPPA（パーソナル・パッケージ・アーカイブ）のいずれかからインストールが可能だ。
例えばUbuntuの公式パッケージからインストールするには、以下のコマンドを実行すればよい（記事執筆時点でバージョンは2.7.4）。
|
sudo apt install -y git
|
もしくはPPAを使用して、最新版パッケージをインストールするには、以下のコマンドを実行すればよい（記事執筆時点で2.14.2-1）。
|
sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt upgrade
sudo apt install -y git
|
Node.js
Node.jsも公式パッケージもしくはプライベートリポジトリからインストール可能だ。
Ubuntuの公式パッケージからインストールする方法は以下の通り（記事執筆時点で4.7.2）。
|
sudo apt install -y nodejs
|
NodeSourceの配布サイトから、最新版パッケージをインストールするには以下のコマンドを実行する（記事執筆時点で8.7）。
|
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt install -y nodejs
|
nginx
最近ではApache httpdに代わってWebサーバー「nginx」が人気を博している。そのnginxのUbuntuパッケージをインストールしてみよう。具体的にはリスト10の手順で、aptのパッケージリストを更新してから、nginxパッケージをインストールする。
nginxやApache httpdは既定で80/tcpを使用する。WindowsでIISやSkypeといった80/tcpを使用するアプリケーションを起動していると使用できなくなるので、注意してほしい。
|
sudo apt update
sudo apt install -y nginx
|
Ruby
スクリプト言語として人気の高い、RubyをUbuntuパッケージからインストールする方法を紹介する。以下のコマンドでRuby 2.3.1（※執筆時点）がインストールされる。
|
sudo apt update
sudo apt install -y ruby
|
PHP
WordPressをはじめ、世界の多くのブログエンジンおよびCMSの開発言語であるPHPをUbuntuパッケージからインストールする方法を紹介する。以下のコマンドでPHP 7.0.22（※執筆時点）がインストールされる。
|
sudo apt update
sudo apt install -y php
|
Java
オラクル（Oracle）から配布されているJDKもPPAからインストールが可能だ。執筆時点の最新版であるJDK 8をインストールする方法を紹介する。最後のapt installコマンドを実行すると、ライセンス同意画面が表示される。コンソールに表示されるOracle Binary Code licenseに同意すると、インストールが開始される。
|
sudo add-repository ppa:webupd8team/java
sudo apt update
sudo apt install -y oracle-java8-installer
|
Go（golang）
グーグル（Google）が作ったプログラミング言語Go（golangとも呼ばれる）をインストールする方法を紹介する。GoはDockerを作った言語としても知られている。
|
sudo apt update
sudo apt install -y golang
|
MySQL
多くのサービスで使われているRDBMSであるMySQLもインストールできる。
|
sudo apt update
sudo apt install -y mysql-server
|
まとめ
いかがだっただろうか？ WSLを使用できるようになったことで、従来のようにWindows上でLinux仮想化環境を構築したり、別途Linuxマシンを用意したりすることに比べれば、非常に低コストでLinux環境をWindowsだけで完結させられるようになった。
もちろん、まだまだ足りない機能もたくさんあるとは思うが（例えばdaemonを動かす機能、特にDockerコンテナーが動かせること、topコマンドによる稼働状況の確認などが考えられる）、現状でもLinuxでしか動かなかった数多くのツールをWindows上でそのまま動かせるようになっており、例えば「Linux用のバイナリを生成するためのビルドエージェントを実行する」といった用途においては非常に便利に活用できるだろう。
次回は、より実践的な内容として、WSLとWindowsでファイルシステムを上手に相互運用するためのヒントや、WSLを活用してクロスプラットフォームなASP.NET Core開発やLinuxアプリケーションの開発＆デバッグを行う方法を説明する。
【改訂・更新履歴】
- 2016/08/23
-
初版： Windows 10 Anniversary Update対応版
- 2017/04/06
-
第2版： Windows 10 Creators Update対応版
- 2017/05/09
-
更新： プレビュー版から正式版へのマイナーアップデート
- 2017/10/25
-
第3版： Windows 10 Fall Creators Update対応版
1. 【現在、表示中】≫ Windows Subsystem for Linuxとは？ そのインストールと使い方
Fall Creators Updateで正式版として提供されることになった「Windows 10上で動作するLinuxサブシステム」によるBashシェルの基礎を理解・マスターすることをゴールとして、Windows Subsystem for Linux（WSL、旧称：Bash on Ubuntu on Windows）の概要から、インストール方法までを解説。また、よくある疑問をQ＆A形式で短くまとめる。
2. Windows Subsystem for Linuxを使って「開発」をしてみよう
WindowsとWSL（Windows Subsystem for Linux）の間でファイルシステムを上手に相互運用するためのヒントや、WSLを活用してクロスプラットフォームな開発を行う方法を説明する。
3. Bash on Ubuntu on Windowsの、Creators Updateでの強化点＆新機能
正式リリースされたWindows 10 Creators Updateで、Bash on Windowsはどう進化するのか？ その強化点と新機能を紹介する。
