Editando arquivos em um ambiente de desenvolvimento do Windows Subsystem for Linux

Question

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

• Construa um projeto usando um conjunto de ferramentas do Linux que não tenha 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 pode modificar arquivos dentro do sistema de arquivos lxss virtual . Modificar diretamente esses arquivos é conhecido 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 ). O conjunto de ferramentas normal funciona corretamente. No entanto, a edição é limitada a qualquer Vim / Emacs baseado em terminal ou qualquer outra coisa que possa ser executada sob um servidor X janky , que é menos suave do 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 no Windows pode ser usado para desenvolvimento. No entanto, o conjunto de ferramentas baseado em Linux é frágil, pois não foi projetado para ser usado em uma "unidade de rede" e pode causar problemas com arquivo assistindo ou bancos de dados .

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

    

Answer 1

Você pode abrir programas do Windows a partir do WSL, mas precisará converter caminhos de arquivo se quiser abrir arquivos do Windows com programas do Windows de dentro do WSL. Eu uso um pequeno script para isso, que você pode encontrar aqui . É comum vincular os caminhos do Linux aos caminhos do Windows (por exemplo, ~/src -> /mnt/c/Users/Documents/src ) e, em seguida, você pode abrir esse caminho de dentro do WSL com cd ~; code "'wslpath src'" .

Se você abrir o vscode a partir do WSL, ele irá esperar que ele seja fechado, para que você saiba quando ele é feito com os arquivos que ele estava editando. Os problemas de banco de dados que você mencionou na maioria das vezes derivam de coisas como inotify não respondendo a eventos que o acionariam no Linux. Infelizmente, isso ainda não está implementado no WSL, então não há um caminho bom para um aplicativo Linux saber quando algum outro processo do Windows fecha um arquivo.

    

Answer 2

Tenho certeza de que pessoas mais inteligentes do que eu olharam para essa questão. Mas eu responderei. Eu sinceramente acredito que a resposta é atualmente não. Existe uma maneira melhor de obter o melhor dos dois mundos, além daqueles que você mencionou (que eu conheço).

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 chegou lá.

    

Answer 3

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

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

Nenhuma delas resolve totalmente os problemas da minha pergunta original, mas eles podem melhorar a usabilidade em certos casos específicos.