Editando arquivos em um ambiente de desenvolvimento Windows Subsystem for Linux

O Windows Subsystem for Linux (WSL) funciona muito bem para disponibilizar a maioria das ferramentas Linux de linha de comando e trabalhar no Windows sem modificações. No entanto, fica um pouco complicado para o desenvolvimento, quando se quer

• Crie um projeto usando uma cadeia de ferramentas Linux que não possua um equivalente do Windows bem suportado (Ruby, Node, etc.)
• Edite arquivos usando um editor de GUI baseado no Windows , como o código do Visual Studio.

O problema é que os aplicativos do Windows não podem modificar arquivos dentro do sistema de arquivos lxss virtual . A modificação direta desses arquivos é conhecida por causar todos os tipos de problemas.

Portanto, parece haver apenas duas opções abaixo do ideal quando se trata de usar o WSL para desenvolvimento:

1. Armazene o projeto em lxss ( /home/foo). A cadeia de ferramentas normal funciona corretamente. No entanto, a edição é limitada ao Vim / Emacs baseado em terminal ou qualquer outro que possa ser executado em um servidor X irregular , o que é menos tranqüilo que os editores nativos em execução no Windows.

2. Armazene o projeto no sistema de arquivos do Windows ( /mnt/c/Users/foo). Agora qualquer editor baseado em Windows pode ser usado para desenvolvimento. No entanto, a cadeia de ferramentas baseada em Linux é frágil, pois não foi projetada para ser usada em uma "unidade de rede" e pode causar problemas na visualização de arquivos ou bancos de dados .

Existe alguma maneira de obter o melhor dos dois mundos aqui - ou seja, poder editar usando um aplicativo nativo do Windows, mas ainda assim ter a cadeia de ferramentas Linux funcionando como normalmente em uma unidade local?

A Microsoft adicionou recentemente um suporte abrangente para isso e deve estar disponível geralmente na atualização de abril de 2019 (19H1). Quando estiver pronto, um servidor 9P será executado em segundo plano sempre que uma distribuição Linux estiver em execução. O servidor 9P poderá lidar com os metadados do sistema de arquivos Linux e o Windows poderá tratá-lo como uma unidade de rede para que possa acessá-lo com segurança. Você pode ler sobre isso em https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/ .

Com o novo recurso, você poderá acessar com segurança os arquivos do sistema de arquivos Windows e Linux a partir do Windows, desde que passe pelo servidor 9P. Isso será tratado de forma nativa na WSL. Por exemplo, na linha de comando da WSL, você poderá digitar code /mnt/c/Users/username/src/windows-file.txtpara abrir um arquivo do Windows no VS Code ou digitar code /home/username/src/linux-file.txtpara abrir um arquivo do Linux no VS Code.

Se você não faz parte do Windows Insider Program, ainda não terá acesso a isso, portanto ainda precisará usar um método mais antigo, como o wslpath.

O wslpath será convertido entre os caminhos no estilo Windows e Linux, para que você possa abrir facilmente arquivos do Windows na linha de comando da WSL. Conforme https://github.com/Microsoft/WSL/issues/3146#issuecomment-388118689 , ele se recusará a converter os caminhos do sistema de arquivos Linux (ou seja,% AppData% \ lxss), porque sem o 9P não é seguro modificar esses arquivos do Windows . Isso significa que você não pode abrir /home/username/src/linux-file.txt, mas pode usar code "$(wslpath -aw /mnt/c/Users/username/src/windows-file.txt)".

No passado, havia várias ferramentas de terceiros para executar a mesma conversão, mas o wslpath faz isso de forma nativa - na verdade, ls -l /bin/wslpathmostra que é apenas um link para / init.

Tenho certeza de que pessoas mais inteligentes do que eu analisaram esta questão. Mas eu atendo. Sinceramente, acredito que a resposta seja não. Existe uma maneira melhor de obter o melhor dos dois mundos, além dos mencionados por você (que eu saiba).

Tenho certeza de que não é a resposta que alguém quer, mas acho que é a resposta correta. Eu sei que é algo que a Microsoft está tentando tornar mais suave, mas ainda não está lá.

No primeiro semestre de 2018, a Microsoft lançou algumas melhorias na WSL que abordam alguns desses problemas:

• No Insider Build 17063 e posterior, melhorias no sistema de arquivos permitem que os utilitários Linux vejam mais do que eles esperam nos arquivos DrvFs.
• Desde o final de 2017, o Visual Studio Code pode executar a versão WSL do Node diretamente .

Nenhum deles aborda completamente os problemas da minha pergunta original, mas eles podem melhorar a usabilidade em certos casos específicos.

Se você deseja executar comandos linux e editar com os editores do Windows. Você pode manter seu código-fonte (que você deseja editar e testar), em algum lugar do seu sistema de arquivos (como c: \ source \) e acessá-lo no console linux através de / mnt / c / source. Espero que isto ajude.

Agora o Visual Studio Code suporta (como eu estou usando). "Extensão WSL", que permite executar arquivos / pasta CRUD (criar, ler, atualizar, excluir) / pasta a partir do local do Linux. Embora eu ainda esteja lutando para obter a mesma configuração para o atom, que foi minha escolha de editor para desenvolvimento de aplicativos Rails na plataforma Linux.