最近WSLでVSCodeを触ってイラッとしたこと

はじまり

まずはWSLのインストール

ここは本題ではないので殴り書きしておきます。

1. 「スタートメニュー」→「PowerShell」と入力→右クリック→「管理者として実行」
2. 「wsl --install」を実行。
3. PCを再起動。
4. Ubuntuを起動する。Ubuntuが起動されなければ、コントロールパネルを開いて、「プログラムのアンインストールまたは変更」＞「Windowsの機能の有効化または無効化」＞「Linux用Windowsサブシステム」にチェック＞再起動。「スタートメニュー」→「PowerShell」と入力→右クリック→「管理者として実行」→「wsl --install -d Ubuntu-24.04」を実行してディストロをインストールする。
5. Ubuntuのユーザー名とパスワードを設定する。
6. これで基本的なWSL2のインストールは完了。

WSLのバージョンを確認してみよう

まずは自分の環境を確認しておきましょう。WSLのバージョンは wsl --version コマンドで確認できます。

WSL バージョン: 2.4.12.0
カーネル バージョン: 5.15.167.4-1
WSLg バージョン: 1.0.65
MSRDC バージョン: 1.2.5716
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.26100.3476

ふ～ん。

なるほど、WSL2を使っているわけですね。WSL2はHyper-Vベースの仮想化技術を使っているので、WSL1よりもパフォーマンスが良いと言われています。ただ、その分ファイルシステムの扱いなどで思わぬ落とし穴があったりするらしい・・・。

Ubuntuのバージョンも確認しておこう

続いて、Ubuntu自体のバージョンも確認しておきましょう。cat /etc/os-release コマンドで確認できます。

PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="<https://www.ubuntu.com/>"
SUPPORT_URL="<https://help.ubuntu.com/>"
BUG_REPORT_URL="<https://bugs.launchpad.net/ubuntu/>"
PRIVACY_POLICY_URL="<https://www.ubuntu.com/legal/terms-and-policies/privacy-policy>"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

最新のUbuntu 24.04.2 LTS（Noble Numbat）を使っているようですね。LTSなので長期サポートがあり、安定して使っていけそうです。

権限の管理が面倒すぎる問題

さて、本題に入りましょう。WSLでVSCodeを使っていて最初にイラッとしたのが、権限管理の問題です。WSLとWindowsの間でファイルをやり取りすると面倒なことになることがある。

VSCodeを立ち上げるドライブには気を付けるべき

WSLでVSCodeを使う場合、どのドライブからVSCodeを立ち上げるかが重要になります。例えば、WSLのドライブから立ち上げたワークスペースをCドライブに保存したりすると、ユーザの権限が無くなってファイルを保存できなくなることがあります。

私の場合は、Cドライブにgit cloneしたリポジトリをWSLに移動して、VSCode上で触ろうとしたら引っ掛かりました。

# こんな感じでWindowsのCドライブからクローンしたリポジトリを移動します。
git clone <https://github.com/example/repo.git> /mnt/c/Users/username/projects/repo

移動したファイルをVSCodeで編集した後にctrl + Sなりを押すんですが、保存できなくなるんですよね。なので、その事象に気付かずに編集し続けた内容が保存できずに立ち往生してしまう・・・。

対策

基本的には、WSL内で作業する場合は、WSLのファイルシステム内（/home/username/以下）からその編集したいファイルに関する作業を始めるのがベストな気がします。Windowsに召喚してしまったファイルは、WindowsからWSL上のLinuxに移動するのではなく、Linuxに直接呼び起こすようにする。

例えば、Gitリポジトリなどを扱う場合は、最初からWSL内にクローンするか、Windowsのファイルシステム上で完結させるかを決めておく。

改行コードがいつの間にかCRLFになっている恐怖

次に大きな問題が、改行コードの問題です。これがかなり面倒くさかった・・・。Linuxの改行コードであるLFが、いつの間にかCRLFになっていて、シェルスクリプトが動かなくなったりする問題です。

改行コード問題の発見

この問題は、PowerShellファイルを弄る時にもたまに遭遇する事象です。（もしかしたら、先程の権限問題で権限を割り当てる的な処理をしたのですがそれが原因なのか・・・？　うーんまあよく分かりませんが、原因の深掘りはしませんでした・・・。）

この事象のせいで、ShellスクリプトファイルからコピペしたコードをBash上に貼り付けて実行することは可能ですが、Shellスクリプトファイル自体から実行することができなくなります。

Web上で、Claude 3.7 Sonnetからこんな感じのコードをファイルから実行して問題の切り分けをするように提案されましたが、この内容だと改行コードをパースしないので当該エラーを導き出すことができませんでした。（ClineとかCursorとかClaude Desktopだったら見つけられたのかなぁ？）

#!/bin/bash

# テスト用の簡単なエイリアス
alias test='echo "テスト成功"'

改行コード問題の発見方法

この改行コード問題に気付けたのは、以下のように全ての処理をコメントアウトして実行したからです。改行コードをパースすると、「: command not found」というエラーになります。ちなみにそのエラーはコメントアウトを外しても同様に発生していました。例えば以下の内容を「crlf.bash」というファイルで改行コードがCRLFの状態で実行するとエラーになりました。

# #!/bin/bash

# #==============================================================#
# ##         New Commands                                      ##
# #==============================================================#
# function getpids() {
#   echo `ps x | grep $1 | awk '{print $1}'`
# }

# function du-ah() {
#   # e.g. du-ah / 20
#   du -ah $1 | sort -rh | head -n $2
# }

# function git-erase() {
#   # e.g. git-erase credential.json
#   git filter-branch --force --index-filter "git rm --cached --ignore-unmatch $1" -- --all
# }

# ...

source ./crlf.bash

そして、この改行コード問題はどこで発生したのかが分からないのですが、私の場合は全てのファイルで発生していました。Gitの差分が100件以上になっていたので絶対おかしいとは思っていましたが、まさか全てのファイルの改行コードがCRLFになっているとは思わなかったので・・・。パッと見では分かりませんし。

改行コード問題の影響

そしてそして、このGitの差分100件をコミットしてリモートにプッシュしてCIを回した時にエラーが発生しました。いつも発生しない場所かつ編集していないファイルでエラーが発生していたので、改行コードだと悟りました・・・。Bash実行時に改行コードで詰まると以下のようなエラーメッセージが出ますね。

env: 'bash\\r': No such file or directory
env: use -[v]S to pass options in shebang lines

あーー・・・・・・、これは見覚えのあるエラーメッセージです。\\rという文字が入っているということは、まさにCRLF問題ですね。

改行コード問題の解決策

そのため、全てのファイルをCRLF改行コードからLF改行コードに変更しました。WSLにすればバラ色のLinux開発環境をWindows上で堪能することができると思ったのですが・・・、そんなに世の中うまく行かないようです・・・。

以下のコマンドで自分のdotfilesリポジトリのファイルを全てLF改行コードに直しました。

sudo apt-get install dos2unix # for Ubuntu
function change_carriage_return() {
  # 'change_carriage_return' changes the line feed code to the carriage return code.
  # e.g. change_carriage_return dir_1
  find $1 -type f -exec dos2unix {} \\;
}
change_carriage_return ./dotfiles

これで一応解決しましたが、根本的な原因が分からないので、また同じ問題が発生する可能性があります・・・。VSCodeの設定で改行コードをLFに固定するなどの対策が考えられますね。

「Could not resolve host: github.com」という謎のエラー

次に遭遇した問題は、GitHubに接続できなくなる問題です。ブラウザではGitHubにアクセスできるのに、WSL上のgitコマンドだけ繋がらないという謎の現象です。発生したりしなかったりして再現性を掴めていません。

事象

例えば、「git clone https://github.com/XXX/YYYY」したら、「Could not resolve host: github.com」というエラーメッセージが表示されました・・・。

git clone <https://github.com/example/repo.git>
# Cloning into 'repo'...
# fatal: unable to access '<https://github.com/example/repo.git/>': Could not resolve host: github.com

解決策

結論：Windowsを再起動したら直りました・・・。原因は未だに分かりません。ブラウザではGitHubにアクセスできていたので、WSL上での名前解決ができなかったんですかねぇ。

プロキシサーバを経る過程で何かしらの問題が起きていることもあるらしいです。以下のコマンドを打ったら直ることもありました。

# プロキシ設定を確認
env | grep -i proxy

# プロキシ設定を一時的に解除
unset http_proxy
unset https_proxy

また、以下の対処法も試してみましたが、Windows 11では多分できません。私は試しましたが出来ませんでした。（LxssManagerというサービスが見つからないらしい。）

wsl --shutdown
Get-Service LxssManager | Restart-Service

次回、同じようなことが起きたら、以下のコマンドを実行してみることに決めました。これでWindowsを再起動しないで済むなら嬉しいのですが・・・。（実際にこの後試してみて・・・、結局出来ませんでした）。

wsl --shutdown
Get-Service WSLService | Restart-Service

その他諸々の、イラッとしなかった作業

ここからは、イラッとまではしなかったものの、WSLでVSCodeを使う上で行った設定や遭遇した問題について紹介します。

Gitの更新をVSCodeのGUI上で見れない問題

これは、Gitリポジトリなどのディレクトリをワークスペースとして追加した際に発生します。1つのワークスペース内で作業を完結させる場合は問題ないのですが、ワークスペースとして追加した方が可視性が上がるっていうメリットもあるからなぁ・・・。一長一短ですか。

VSCodeの右下に表示される「Manage unsafe repositories」をクリックすると、Gitの更新をVSCode上で管理することができます。別ドライブで動いている分、権限周りがとりあえず面倒くさいですね。

これは、WSLとWindowsの間でのセキュリティ上の問題で、WSL内のGitリポジトリをVSCodeが「安全でない」と判断しているためです。一度許可すれば問題なく使えるようになりますが、新しいリポジトリごとに毎回この操作が必要になるのは少し面倒です。

Python 3がプリインストールされている場合がある

さて、開発および実行環境としてまずはPythonをインストールしようとしました。その際に、以下の記事を参考にさせて頂きました。

Python 3をインストールしUbuntu 20.04サーバーにプログラミング環境を設定する方法 | DigitalOcean

このチュートリアルでは、Ubuntu 20.24 サーバーでPython 3のプログラミング環境をセットアップする方法を学びます。サーバーでのプログラミングには多くの利点があり、開発プロジェクト間のコラボレーションをサポートします。このチュ...

www.digitalocean.com

Pythonをインストールしようとしましたが、Ubuntuの場合は、遅くてもUbuntu 20.04からPython 3がプリインストールされているらしいです。なので、Pythonをインストールする前に、Pythonのバージョンを確認しましょう。

sudo apt update
sudo apt -y upgrade

python3 -V
# いつも使っているのはpythonなのでalias
alias python='python3'

しかし、pipがなぜか入っていなかったので、以下を実行しました。

sudo apt install -y python3-pip
pip -V

venvも入っていなかったので、以下を実行しました。

sudo apt install python3.12-venv

これで、Python環境の基本的なセットアップは完了です。WSLの良いところは、このようにLinuxネイティブの開発環境をすぐに構築できることですね。それは良いことです。

Goもインストールしたい

次に、Goも使いたかったので、まずはGoがインストールされているかどうかを確認します。

go version

Goのchange listを確認します。

snap info go

Goをインストールしようとしました。（snapは、色々なLinuxディストロに使えるパッケージリストらしいです。aptは、Debian系専用ですけど。）

sudo snap install go

しかし、以下のエラーが表示されて、インストール出来ませんでした。クラシックなGoならインストール出来るらしいですけども。

error: This revision of snap "go" was published using classic confinement and thus may perform
       arbitrary system changes outside of the security sandbox that snaps are usually confined to,
       which may put your system at risk.

       If you understand and want to proceed repeat the command including --classic.

今回は素直に、aptのgolang-goにしておくことにしました。

sudo apt install golang-go
go version

これでインストール完了です。

VSCodeでGoの静的チェック（フォーマッタ）を動かす問題

Goをインストール出来たのは良かったのですが、その後、VSCodeでGoの静的チェック（フォーマッタ）を動かす、つまりGoの拡張機能を動かすことができませんでした・・・。

Goの拡張機能がちゃんと動いていないと、こんなエラーメッセージが表示されました。

Error loading workspace folders (expected 1, got 0) failed to load view for file:////wsl.localhost/Ubuntu-24.04/wsl.localhost/Ubuntu-24.04/home/user-name/my-repository/mypkg: failed to get workspace configuration from client (file:////wsl.localhost/Ubuntu-24.04/wsl.localhost/Ubuntu-24.04/home/user-name/my-repository/mypkg): Request workspace/configuration failed with message: [UriError]: If a URI does not contain an authority component, then the path cannot begin with two slash characters (“//”)

以下、Goの拡張機能をアクティブにするために試してみたことを記します。

settings.jsonを編集する際に、以下の機能を設定する時にリポジトリにある資料を参考にしました。

tools/gopls/doc/settings.md at master · golang/tools

Go Tools. Contribute to golang/tools development by creating an account on GitHub.

github.com

試したこと一覧です。1回しか作業しなかったので再現性は確認できていませんが、個人的に多分必要だと思ったことは強調しておきます。

• VSCodeがインストールされているドライブにGoパッケージをインストールした。つまり、Windowsにインストールし直した。
• VSCodeに「WSL」（identifier: ms-vscode-remote.remote-wsl）をインストール。（多分必要。）
• VSCodeのsettings.jsonに後述のフィールドを記述する。（"gopls"は多分必要。）
• VSCodeをUbuntu上で開き直す。「code .」をWSLコンソール上で実行し直します。（必要。）
• すると、右下の方で「Reopen folder in WSL」的なニュアンスのメッセージが表示されるので、そのメッセージ内のボタンから、WSLでVSCodeを開いた。（必要。）
• すると、WSLでVSCodeを開くので、そこでGoの拡張機能をインストールする。

VSCodeのsettings.jsonに記述したフィールドは下記のものになります。

...

"[go]": {
  "editor.suggest.snippetsPreventQuickSuggestions": false,
  "editor.defaultFormatter": "golang.go"
},
"go.formatTool": "gofmt",
"go.toolsEnvVars": {
  "GO111MODULE": "on"
},
"gopls": {
  "expandWorkspaceToModule": true
},

...

そうすると、フォーマッタが発動！　・・・嬉しいけど最小構成が不明だったので腑に落ちませんでした。

まとめ

WSLでVSCodeを使うことで、Windows上でLinux環境を利用できるという素晴らしいメリットがありますが、いくつかの落とし穴もあることが分かりました。

1. 権限管理の問題：WSLとWindowsの間でファイルをやり取りする際に権限が変わることがある
2. 改行コードの問題：いつの間にかCRLFになっていて、シェルスクリプトが動かなくなる
3. GitHub接続の問題：突然GitHubに接続できなくなり、Windowsの再起動が必要になることがある。再起動しなくても直ることもある。
4. その他の設定問題：Gitの更新表示、Python/Goの環境設定など

これらの問題を把握し、適切に対処することで、WSL+VSCodeの環境をより快適に使うことが出来るでしょう。特に、改行コードの問題は気付きにくいので注意が必要です。

おしまい

以上になります！