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

Подсистема Windows для Linux (WSL) прекрасно работает для обеспечения доступности большинства инструментов Linux для командной строки и работы в Windows без изменений. Тем не менее, это становится немного сложнее для развития, когда кто-то хочет

• Создайте проект, используя набор инструментов Linux , который не имеет хорошо поддерживаемого эквивалента Windows (Ruby, Node и т. Д.)
• Редактируйте файлы с помощью редактора графического интерфейса пользователя Windows, такого как код Visual Studio.

Проблема в том, что приложения Windows не могут изменять файлы внутри виртуальной файловой системы lxss . Известно, что прямое изменение этих файлов вызывает все виды проблем.

Поэтому, кажется, есть только два неоптимальных варианта использования WSL для разработки:

1. Сохраните проект под lxss ( /home/foo). Обычный набор инструментов работает правильно. Тем не менее, редактирование ограничено либо Vim / Emacs на основе терминала, либо тем, что может быть запущено на опасном X-сервере , что менее плавно, чем в собственных редакторах, работающих в Windows.

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

Есть ли способ получить лучшее из обоих миров - то есть, чтобы иметь возможность редактировать с помощью собственного приложения Windows, но при этом иметь инструментальную цепочку Linux, как это обычно бывает на локальном диске?

Microsoft недавно добавила всестороннюю поддержку для этого, и она должна быть общедоступной в обновлении за апрель 2019 года (19H1). Как только он будет готов, сервер 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, или набрать, code /home/username/src/linux-file.txtчтобы открыть файл Linux в VS Code.

Если вы не являетесь частью программы Windows Insider, у вас еще не будет к ней доступа, поэтому вам все равно придется использовать более старый метод, такой как wslpath.

wslpath преобразует пути в стиле Windows и Linux, чтобы вы могли легко открывать файлы Windows из командной строки WSL. Согласно https://github.com/Microsoft/WSL/issues/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 может запускать версию Node WSL напрямую .

Ни один из них полностью не затрагивает проблемы в моем первоначальном вопросе, но они могут улучшить удобство использования в определенных конкретных случаях.

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

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