Edycja plików w środowisku programistycznym Windows Subsystem for Linux

Podsystem Windows dla systemu Linux (WSL) działa całkiem dobrze, udostępniając większość wiersza poleceń systemu Linux i pracując w systemie Windows bez modyfikacji. Jednak staje się to trochę trudne do rozwoju, gdy ktoś chce

• Zbuduj projekt za pomocą zestawu narzędzi systemu Linux , który nie ma dobrze obsługiwanego odpowiednika systemu Windows (Ruby, węzeł itp.)
• Edytuj pliki za pomocą edytora GUI opartego na systemie Windows, takiego jak kod Visual Studio.

Problem polega na tym, że aplikacje Windows nie mogą modyfikować plików w wirtualnym systemie plików lxss . Wiadomo, że bezpośrednia modyfikacja tych plików powoduje różnego rodzaju problemy.

Dlatego wydaje się, że istnieją tylko dwie nieoptymalne opcje, jeśli chodzi o użycie WSL do programowania:

1. Zapisz projekt pod lxss ( /home/foo). Normalny łańcuch narzędzi działa poprawnie. Edycja jest jednak ograniczona do Vima / Emacsa opartego na terminalu lub czegokolwiek, co można uruchomić na serwerze janky X , który jest mniej płynny niż natywne edytory działające w systemie Windows.

2. Zapisz projekt w systemie plików Windows ( /mnt/c/Users/foo). Teraz do programowania można użyć dowolnego edytora opartego na systemie Windows. Jednak oparty na Linuksie zestaw narzędzi jest kruchy, ponieważ nie został zaprojektowany do użytku na „dysku sieciowym” i może powodować problemy z oglądaniem plików lub baz danych .

Czy jest jakiś sposób, aby uzyskać to, co najlepsze z obu światów - to znaczy móc edytować przy użyciu natywnej aplikacji Windows, ale nadal mieć łańcuch narzędzi Linux działający tak jak normalnie na dysku lokalnym?

Firma Microsoft dodała ostatnio kompleksową obsługę tego problemu i powinna być ogólnie dostępna w aktualizacji z kwietnia 2019 r. (19H1). Gdy będzie gotowy, serwer 9P będzie działał w tle za każdym razem, gdy działa dystrybucja Linuksa. Serwer 9P będzie w stanie obsłużyć metadane systemu plików Linux, a system Windows będzie mógł traktować go jako dysk sieciowy, aby mógł uzyskać do niego bezpieczny dostęp. Możesz przeczytać o tym na https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/ .

Dzięki nowej funkcji będziesz mógł bezpiecznie uzyskiwać dostęp do plików systemu Windows i Linux z systemu Windows, o ile przejdziesz przez serwer 9P. Będzie to obsługiwane natywnie z poziomu WSL. Na przykład w wierszu polecenia WSL możesz wpisać, code /mnt/c/Users/username/src/windows-file.txtaby otworzyć plik systemu Windows w kodzie VS, lub wpisać, code /home/username/src/linux-file.txtaby otworzyć plik systemu Linux w kodzie VS.

Jeśli nie jesteś uczestnikiem niejawnego programu testów systemu Windows, nie będziesz mieć do niego dostępu, więc nadal będziesz musiał użyć starszej metody, takiej jak wslpath.

Program wslpath skonwertuje ścieżki w stylu Windows i Linux, dzięki czemu można łatwo otwierać pliki Windows z wiersza polecenia WSL. Zgodnie z https://github.com/Microsoft/WSL/issues/3146#issuecomment-388118689 odmówi konwersji ścieżek systemu plików Linux (tj.% AppData% \ lxss), ponieważ bez wersji 9P modyfikowanie tych plików z systemu Windows jest niebezpieczne . Oznacza to, że nie możesz otworzyć /home/username/src/linux-file.txt, ale możesz użyć code "$(wslpath -aw /mnt/c/Users/username/src/windows-file.txt)".

W przeszłości istniało wiele narzędzi innych firm do wykonania tej samej konwersji, ale wslpath robi to natywnie - w rzeczywistości ls -l /bin/wslpathpokazuje, że jest to tylko link do / init.

Jestem pewien, że mądrzejsi ludzie niż ja spojrzeli na to pytanie. Ale odpowiem na to. Szczerze wierzę, że odpowiedź brzmi: nie. Jest lepszy sposób, aby uzyskać to, co najlepsze z obu światów, inne niż te, o których wspominałeś (o których wiem).

Jestem pewien, że nie jest to odpowiedź, której ktoś chce, ale myślę, że to poprawna odpowiedź. Wiem, że to coś, co Microsoft chce sprawić, aby było bardziej płynne, ale jeszcze tego nie ma.

W pierwszej połowie 2018 roku Microsoft wydał kilka ulepszeń w WSL, które rozwiązują niektóre z tych problemów:

• W Insider Build 17063 i nowszych wersjach ulepszenia systemu plików pozwalają narzędziom Linux zobaczyć więcej tego, czego oczekują od plików DrvFs.
• Od końca 2017 roku Visual Studio Code może bezpośrednio uruchamiać wersję Node WSL .

Żadne z nich nie odnosi się w całości do problemów z mojego pierwotnego pytania, ale mogą poprawić użyteczność w niektórych szczególnych przypadkach.

Jeśli chcesz uruchamiać polecenia Linux i edytować za pomocą edytorów Windows. Możesz przechowywać kod źródłowy (który chcesz edytować i testować) gdzieś w swoim systemie plików (np. C: \ source \) I uzyskać do niego dostęp w konsoli Linux poprzez / mnt / c / source. Mam nadzieję że to pomoże.

Teraz Visual Studio Code obsługuje (gdy go używam). „Rozszerzenie WSL”, które umożliwia wykonywanie CRUD (tworzenie, czytanie, aktualizowanie, usuwanie) plików / folderów z lokalizacji Linuksa. Chociaż wciąż mam problemy z uzyskaniem takiej samej konfiguracji dla atomu, co było moim wyborem edytora do tworzenia aplikacji Railsowych na platformie Linux.