Linux開発環境用のWindowsサブシステムでファイルを編集する

Linux用のWindowsサブシステム （WSL）はほとんどのコマンドラインのLinuxツールを利用可能にし、Windows上で変更なしに動作するためにはかなりうまくいきます。しかし、開発には少しトリッキーです。

• を使用してプロジェクトを構築する Linuxツールチェーン それはよくサポートされている同等のWindows（Ruby、Nodeなど）を持っていません
• を使用してファイルを編集する WindowsベースのGUIエディタ Visual Studioのコードなど。

問題は、Windowsアプリが 仮想lxssファイルシステム内のファイルを変更することはできません 。これらのファイルを直接変更すると、あらゆる種類の問題が発生することが知られています。

したがって、開発にWSLを使用することになると、最適とは言えない選択は2つしかないようです。

1. プロジェクトをlxssに保存します（ /home/foo ）通常のツールチェーンは正しく機能します。しかし、編集は端末ベースのVim / Emacsあるいはそれ以外の環境で実行できるものに限られています。 ジャンキーXサーバー これは、Windows上で動作するネイティブエディタよりもスムーズではありません。

2. プロジェクトをWindowsファイルシステムの下に保存します（ /mnt/c/Users/foo ）今すぐWindowsベースのエディタが開発に使用できます。しかし、Linuxベースのツールチェーンは「ネットワークドライブ」で使用するようには設計されていないため脆弱であり、次のような問題を引き起こす可能性があります。 ファイル監視 または データベース 。

ここで両方の長所を活用する方法はありますか。つまり、ネイティブのWindowsアプリケーションを使用して編集できるようにしながら、Linuxツールチェーンを通常どおりローカルドライブ上で機能させることができますか。

WSL内からWindowsプログラムを開くことができますが、WSL内からWindowsプログラムを使用してWindowsファイルを開く場合は、ファイルパスを変換する必要があります。 wsltoolsがこれを行います。

あなたがWSLからvscodeを開くと、それはそれが閉じるのを待つでしょう、それでそれが編集されていたどんなファイルでもそれがいつ終わったかわかるでしょう。あなたが言及したデータベースの問題の大部分は、inotifyのようなものがLinuxでそれを引き起こすであろうイベントに応答しないことから生じます。残念ながら、これはWSLにまだ実装されていないので、ありません。 良い 他のWindowsプロセスがファイルを閉じるタイミングをLinuxアプリケーションが認識するための方法。

私はこの質問を見てきたよりも賢い人たちだと思います。しかし私はそれに答えます。私は正直に答えが現在ノーであると信じています。あなたが（私が知っていることを）言及したもの以外の両方の世界を最大限に活用するためのより良い方法があります。

私はそれが誰かが望む答えではないと確信しています、しかし私はそれが正しい答えだと思います。 Microsoftがより円滑にするための努力をしているのは確かですが、まだ実現していません。

2018年の前半に、マイクロソフトはこれらの問題のいくつかに対処するいくつかの改良をWSLにリリースしました：

• インサイダービルド17063年以降 ファイルシステムの改善 LinuxユーティリティがDrvFsファイルに期待することの詳細を確認できるようにします。
• 2017年後半以降、Visual Studio Codeは WSL版のNodeを直接実行する 。

どちらも私の最初の質問の問題に完全には対処していませんが、特定のケースでは使い勝手が向上する可能性があります。