Редагування файлів у підсистемі Windows для середовища розробки Linux

Підсистема Windows для Linux (WSL) працює досить добре для того, щоб зробити більшість інструментів Linux командного рядка доступними та працювати в Windows без змін. Однак це стає дещо складним для розвитку, коли хочеться

• Створіть проект за допомогою ланцюжка інструментів Linux, що не має добре підтримуваного еквівалента Windows (Ruby, Node тощо)
• Редагуйте файли, використовуючи редактор GUI на базі Windows, наприклад код Visual Studio.

Проблема полягає в тому, що програми Windows не можуть змінювати файли всередині віртуальної файлової системи lxss . Відомо, що безпосередньо модифікація цих файлів викликає всілякі проблеми.

Тому, мабуть, є лише два неоптимальні варіанти, коли мова йде про використання WSL для розробки:

1. Зберігайте проект під lxss ( /home/foo). Звичайна ланцюжок інструментів працює належним чином. Однак редагування обмежується або Vim / Emacs на базі терміналу, або будь-яким іншим, що може бути запущено під сервером janky X , який менш гладкий, ніж рідні редактори, що працюють у Windows.

2. Зберігайте проект у файловій системі Windows ( /mnt/c/Users/foo). Тепер для розробки можна використовувати будь-який редактор на базі Windows. Однак ланцюжок інструментів на базі Linux є крихкою, оскільки не розроблена для використання на "мережевому диску" і може спричинити проблеми з переглядом файлів або базами даних .

Чи є якийсь спосіб отримати найкраще з обох світів тут - тобто мати змогу редагувати за допомогою нативного додатка Windows, але все ж працювати з ланцюжком інструментів Linux так, як це робиться на локальному диску?

Microsoft нещодавно додала всебічну підтримку для цього, і вона повинна бути загальнодоступною в оновленнях у квітні 2019 року (19-го півріччя). Як тільки він буде готовий, 9P-сервер запускатиметься у фоновому режимі, коли працює дистрибутив Linux. Сервер 9P зможе обробляти метадані файлової системи Linux, а Windows зможе трактувати це як мережевий диск, щоб він міг безпечно отримати доступ до нього. Ви можете прочитати про це за адресою https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/ .

За допомогою нової функції ви зможете безпечно отримувати доступ до файлів файлової системи Windows та Linux з Windows, поки ви проходите через сервер 9P. Це буде вирішуватися на самому місці в межах WSL. Наприклад, з командного рядка WSL ви зможете набрати текст, code /mnt/c/Users/username/src/windows-file.txtщоб відкрити файл Windows у коді VS або ввести, code /home/username/src/linux-file.txtщоб відкрити файл Linux у коді VS.

Якщо ви не входите в програму Windows Insider, ви до цього часу не матимете доступу, тому вам все одно доведеться використовувати старіший метод, наприклад, wslpath.

wslpath буде конвертувати між шляхами в стилі Windows та Linux, щоб ви могли легко відкривати файли Windows з командного рядка WSL. Відповідно до https://github.com/Microsoft/WSL/isissue/3146#issuecomment-388118689 , він відмовиться конвертувати шляхи файлової системи Linux (тобто% AppData% \ lxss), оскільки без 9P небезпечно змінювати ці файли з Windows . Це означає, що ви не можете відкрити /home/username/src/linux-file.txt, але ви можете використовувати code "$(wslpath -aw /mnt/c/Users/username/src/windows-file.txt)".

Раніше існувало ряд сторонніх інструментів для здійснення тієї ж конверсії, але wslpath робить це на самому собі - насправді це ls -l /bin/wslpathпоказує, що це лише посилання на / init.

Я впевнений, що розумніші люди, ніж я, дивились на це питання. Але я відповім на це. Я чесно вважаю, що відповідь наразі - ні. Є кращий спосіб отримати найкраще з обох світів, крім того, про який ви згадали (Про що я знаю).

Я впевнений, що це не відповідь, хто хоче, але я думаю, що це правильна відповідь. Я знаю, що Microsoft намагається зробити більш гладким, але цього ще немає.

У першій половині 2018 року Microsoft випустила деякі вдосконалення WSL, які стосуються деяких із цих питань:

• В Insider Build 17063 і пізніших версіях удосконалення файлової системи дозволяють утилітам Linux бачити більше того, що вони очікують від файлів DrvFs.
• З кінця 2017 року Visual Studio Code може запускати WSL-версію Node безпосередньо .

Жоден із них повністю не вирішує проблеми в моєму первісному запитанні, але це може покращити зручність використання в певних конкретних випадках.

Якщо ви хочете запускати команди Linux та редагувати за допомогою редакторів Windows. Ви можете зберігати свій вихідний код (який ви хочете відредагувати та протестувати) десь у вашій файловій системі (наприклад, c: \ source \) та отримати доступ до цього в консолі Linux через / mnt / c / source. Сподіваюсь, це допомагає.

Тепер Visual Studio Code підтримує (як я його використовую). "Розширення WSL", яке дозволяє виконувати CRUD (створювати, читати, оновлювати, видаляти) файли / папки з локації Linux. Хоча я все ще намагаюся отримати таку ж установку для atom, яка була моїм вибором редактора для розробки додатків Rails на платформі Linux.