Edición de archivos en un entorno de desarrollo de Windows Subsystem for Linux

Windows Subsystem for Linux (WSL) funciona bastante bien para hacer que la mayoría de las herramientas Linux de línea de comandos estén disponibles y funcionen en Windows sin modificaciones. Sin embargo, se vuelve un poco complicado para el desarrollo, cuando uno quiere

• Cree un proyecto utilizando una cadena de herramientas de Linux que no tenga un equivalente de Windows bien compatible (Ruby, Node, etc.)
• Edite archivos con un editor de GUI basado en Windows , como el código de Visual Studio.

El problema es que las aplicaciones de Windows no pueden modificar archivos dentro del sistema de archivos virtual lxss . Se sabe que la modificación directa de estos archivos causa todo tipo de problemas.

Por lo tanto, parece que solo hay dos opciones subóptimas cuando se trata de usar WSL para el desarrollo:

1. Almacene el proyecto en lxss ( /home/foo). La cadena de herramientas normal funciona correctamente. Sin embargo, la edición se limita a Vim / Emacs basado en terminal o lo que se pueda ejecutar en un servidor X de Janky , que es menos fluido que los editores nativos que se ejecutan en Windows.

2. Almacene el proyecto en el sistema de archivos de Windows ( /mnt/c/Users/foo). Ahora cualquier editor basado en Windows puede usarse para el desarrollo. Sin embargo, la cadena de herramientas basada en Linux es frágil ya que no está diseñada para usarse en una "unidad de red" y puede causar problemas con la observación de archivos o las bases de datos .

¿Hay alguna forma de obtener lo mejor de ambos mundos aquí, es decir, poder editar usando una aplicación nativa de Windows, pero aún así tener la cadena de herramientas de Linux funcionando como lo haría normalmente en un disco local?

Microsoft ha agregado recientemente soporte integral para esto, y debería estar disponible en general en la actualización de abril de 2019 (19H1). Una vez que esté listo, un servidor 9P se ejecutará en segundo plano siempre que se ejecute una distribución de Linux. El servidor 9P podrá manejar metadatos del sistema de archivos de Linux, y Windows podrá tratarlo como una unidad de red para que pueda acceder a él de manera segura. Puede leer sobre esto en https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/ .

Con la nueva función, podrá acceder de forma segura a los archivos del sistema de archivos de Windows y Linux desde Windows, siempre que pase por el servidor 9P. Esto se manejará de forma nativa desde WSL. Por ejemplo, desde la línea de comandos de WSL podrá escribir code /mnt/c/Users/username/src/windows-file.txtpara abrir un archivo de Windows en VS Code, o escribir code /home/username/src/linux-file.txtpara abrir un archivo de Linux en VS Code.

Si no forma parte del Programa Windows Insider, aún no tendrá acceso a este, por lo que deberá seguir utilizando un método anterior, como wslpath.

wslpath convertirá entre rutas de estilo Windows y Linux para que pueda abrir fácilmente archivos de Windows desde la línea de comandos WSL. Según https://github.com/Microsoft/WSL/issues/3146#issuecomment-388118689 , se negará a convertir las rutas del sistema de archivos de Linux (es decir,% AppData% \ lxss), porque sin 9P no es seguro modificar estos archivos desde Windows . Esto significa que no puede abrir /home/username/src/linux-file.txt, pero puede usar code "$(wslpath -aw /mnt/c/Users/username/src/windows-file.txt)".

En el pasado, había una serie de herramientas de terceros para realizar la misma conversión, pero wslpath lo hace de forma nativa; de hecho, ls -l /bin/wslpathmuestra que es solo un enlace a / init.

Estoy seguro de que personas más inteligentes que yo han analizado esta pregunta. Pero lo responderé. Sinceramente, creo que la respuesta es actualmente no. Hay una mejor manera de obtener lo mejor de ambos mundos, aparte de los que ha mencionado (que yo sepa).

Estoy seguro de que no es la respuesta que alguien quiere, pero creo que es la respuesta correcta. Sé que es algo que Microsoft está tratando de suavizar, pero aún no está allí.

En la primera mitad de 2018, Microsoft lanzó algunas mejoras a WSL que abordan algunos de estos problemas:

• En Insider Build 17063 y posteriores, las mejoras del sistema de archivos permiten a las utilidades de Linux ver más de lo que esperan en los archivos DrvF.
• Desde finales de 2017, Visual Studio Code puede ejecutar la versión WSL de Node directamente .

Ninguno de estos aborda completamente los problemas en mi pregunta original, pero pueden mejorar la usabilidad en ciertos casos específicos.

Si desea ejecutar comandos de Linux y editar con editores de Windows. Puede mantener su código fuente (que desea editar y probar), en algún lugar de su sistema de archivos (como c: \ source \) y acceder a eso en la consola de Linux a través de / mnt / c / source. Espero que esto ayude.

Ahora Visual Studio Code es compatible (como lo estoy usando). "Extensión WSL" que le permite realizar archivos / carpetas CRUD (Crear, leer, actualizar, eliminar) desde la ubicación de Linux. Aunque todavía estoy luchando por obtener la misma configuración para atom, que fue mi elección de editor para el desarrollo de aplicaciones Rails en la plataforma Linux.