Existem pessoas que passam a maior parte do tempo no console, outras que usam o terminal, se necessário, executando algo de acordo com as instruções. Mas acho que todo especialista em TI, seja ele desenvolvedor, administrador de sistemas, engenheiro de rede ou mesmo desenvolvedor sênior do yaml, usa a interface da linha de comando. Nem todo mundo pensa em melhorar o ambiente de trabalho na CLI e aumentar a produtividade no terminal. Gostaria de compartilhar minha experiência na configuração do ambiente para trabalhar com o Linux a partir do Windows.



No artigo, você aprenderá quais ferramentas e qual terminal atualmente é usado para executar aplicativos Linux no Windows 10. Falaremos sobre o WSL 2 e o Windows Terminal , que estão ganhando cada vez mais popularidade entre os usuários que precisam do Linux para funcionar. Como a maioria dos meus casos de uso está relacionada à conexão remota via SSH, a maioria das informações será relevante para casos de conexões remotas, com todos os recursos associados a isso (encaminhamento de chaves ssh via agente ssh, encaminhamento do X-server, gerenciamento de conexões etc.) )

Atenção! Sob o recorte, muitas fotos e gif encolhido, mas às vezes volumoso, é recomendável abrir o artigo se você tiver acesso adequado à Internet. Entre em contato com o gato se você estiver interessado em executar utilitários Linux no Windows, otimizar seu trabalho no ambiente CLI ou se você gosta de textos técnicos e terminais coloridos. Tentei alegrar o texto com screencasts e capturas de tela do terminal, para que não fosse chato.

1. Introdução

Tanto no meu laptop de casa como no de trabalho, o único sistema operacional que tenho atualmente é o Windows 10 e, neste ano, finalmente passei a usar apenas WSL em vez de VM / dualboot / Cygwin / MinGW. Agora, meu terminal padrão é o shell WSL local, onde posso executar praticamente qualquer tarefa, como no Linux nativo. Além disso, o mini servidor Intel NUC é executado na rede doméstica, na qual o Proxmox é implantado com contêineres LXC e KVM, nos quais o Docker está girando. Eu vou a todas as VMs via SSH, com chaves do diretório do Windows. Muito tempo na atividade profissional ocorre na CLI, com o mesmo servidor e rede. Portanto, sempre há um desejo de lidar com ferramentas para um trabalho mais confortável no terminal, e no Windows sempre houve problemas com isso. Mas agora tudo está mudando.



Este e os artigos subseqüentes estão mais focados nos entusiastas que procuram soluções novas e desejam bombear sua casca. Mas para iniciantes, algo deve ser interessante, embora o artigo tenha sido bastante imerso no tópico e sugira que o leitor tenha algum conhecimento fundamental em Linux. Todas as informações são coletadas com base na experiência pessoal usando o WSL, um terminal, bem como na interminável paginação de problemas de Stack Overflow e Github no processo de melhorar constantemente as configurações e encontrar ferramentas convenientes para o trabalho.

Subsistema Windows para Linux (WSL) 2

Existem vários artigos normais sobre WSL na Internet e no Habr ( uma vez um artigo sobre instalação / configuração do WSL com um servidor X, duas notas sobre o WSL 2, três artigos sobre o desenvolvimento do Python no VSCode com WSL) que descrevem a instalação e a configuração do sistema. No entanto, nem todas as ações de instalação já são relevantes, bem como as restrições com armadilhas estão se tornando menos. Não vou me deter na instalação em detalhes, as instruções para instalar a (segunda) versão atual da WSL estão no site da Microsoft e você também pode encontrar breves tutoriais na Internet.



Agora, a WSL ainda está em desenvolvimento ativo e, recentemente ( junho de 2019 ), foi lançada uma nova versão do WSL 2, que atualmente está disponível apenas para versões novas dos membros do Windows for Windows Insiders. Se possível, recomendo que você atualize imediatamente o WSL para a versão 2, pois melhorou o trabalho de chamadas do sistema, trabalhando com a rede, o FS e, em geral, é construído em uma arquitetura diferente e, segundo alguns relatórios, aumenta em 20 vezes a velocidade em comparação com a primeira versão.

Você pode ver a versão do Windows 10 e do sistema operacional em Iniciar -> Configurações -> Sistema -> Sobre , para instalar o WSL 2, é necessário o Windows 1903 e, pelo menos, a versão 18917 . Se você não é membro do Programa Windows Insider , provavelmente as atualizações não chegarão até uma versão estável. Portanto, se você deseja atualizar para a versão mais recente, pode ativar o acesso antecipado ( Rápido ) em Iniciar -> Configurações -> Atualização e segurança -> Programa Windows Insider , atualizar e desativar outras atualizações. Vale a pena considerar que ainda não serão instaladas atualizações testadas em massa, o que pode afetar a estabilidade.

Lembre-se de que, antes da versão 18995 da compilação, o WSL tinha um erro ao trabalhar com arquivos em discos montados do Windows, expressos como um erro de entrada / saída, apenas reiniciar o WSL ( wsl --shutdown no PowerShell). Em geral, existem muitos erros corrigidos que ainda estão presentes na WSL versão 1 (definida por padrão) e nas distribuições sem visualização do Windows. Se as atualizações do seu sistema operacional forem regulamentadas pelas políticas corporativas, provavelmente as atualizações mais recentes não chegarão e você deve ter isso em mente. Em um dos laptops, eu construí o 18956 e não há atualizações, apesar do fato de a opção Rápida estar selecionada nas configurações do Programa Insider. Um sistema limpo foi instalado em outro laptop há alguns meses e as atualizações chegam e são periodicamente instaladas.

Instale o WSL 2

A WSL exige que o Hyper-V seja ativado porque as distribuições Linux são executadas em VMs leves usando a virtualização Hyper-V.



A seguir, darei uma breve instrução de instalação da distribuição do WSL do CLI PowerShell usando o Kali Linux como exemplo). Se você preferir o Ubuntu ou outra distribuição Linux disponível, substitua o link e os nomes pelos apropriados.

Verifique a versão do Windows Build:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select CurrentBuild

Ative os componentes VirtualMachinePlatform e Microsoft-Windows-Subsystem-Linux:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

Reiniciar
Em seguida, instale a distribuição da Microsoft Store ( https://aka.ms/wslstore ) ou continue a executar no PowerShell:

curl.exe -L -o kali.appx https://aka.ms/wsl-kali-linux-new
Add-AppxPackage .\kali.appx
rm .\kali.appx

Inicie o console da WSL (a distribuição deve aparecer no menu Iniciar, procure pelo nome da distribuição), aguarde o convite para instalar um novo usuário, feche o console.

Agora a distribuição deve aparecer na lista se executada no PowerShell:

wsl -l -v

Se necessário, converta a distribuição no formato WSL versão 2:

wsl --set-version kali-linux 2
wsl --set-default-version 2

Faça do root o usuário padrão (opcional):

kali config --default-user root

Se você receber o erro "Uma tentativa de conexão falhou porque a parte conectada não respondeu adequadamente após um período de tempo ou a conexão estabelecida falhou porque o host conectado falhou ao responder." , Em seguida, você tem uma compilação na qual a próxima (já corrigida em versões recentes) bug. Como de costume, há uma solução alternativa , ou use a distribuição Ubuntu, não tive problemas com ele no mesmo, não na versão mais recente da compilação.

Se necessário, você pode mover o disco virtual WSL para outra partição (diferente de C :), de acordo com as instruções . É melhor fazer isso imediatamente, pois nem tudo pode correr bem.

Isenção de responsabilidade sobre segurança . Na WSL e em outros servidores Linux na rede doméstica, não inicio nenhum sistema crítico e não há outros usuários (exceto eu) na rede, por isso vou fazer root em quase todos os lugares, com autenticação ssh por meio de chaves. Sei que essa não é a melhor prática, mas estou falando de um ambiente de desenvolvimento pessoal e não vejo o ponto de criar um usuário não raiz. Os problemas de segurança não serão considerados neste artigo, vou escrever sobre isso algum dia (sobre como organizar a interação de serviços por meio do TLS com uma renovação centralizada de certificados em uma rede doméstica; sobre sincronização ~ / .ssh / config entre servidores, encaminhamento portas e chaves, etc.).

Configuração WSL

Começando com a compilação 17093 , o arquivo de configuração principal da WSL está localizado no sistema de distribuição FS em /etc/wsl.conf , descreve as configurações que serão aplicadas sempre que a distribuição for inicializada:

• Automount - unidades Windows automount
• Rede - gere arquivos resolv.conf, hosts
• Interoperabilidade - inicie processos do Windows e adicione Windows $ PATH ao Linux $ PATH

Inicialmente, o WSL fica sem essa configuração, deve ser registrado manualmente:

[automount]
enabled = true
root = /mnt
options = "metadata,umask=22,fmask=11"
mountFsTab = true

[network]
generateHosts = true
generateResolvConf = true

[interop]
enabled = true
appendWindowsPath = true

Algumas configurações são usadas com o valor padrão e /etc/wsl.conf vazio, mas para a operação correta com os arquivos, você precisa registrar pelo menos o parâmetro options , caso contrário, os arquivos do Windows terão permissões 777 e isso não poderá ser alterado no Linux.



Você pode reiniciar a distribuição do PowerShell com o comando:

wsl -t kali-linux

Depois disso, você pode atualizar os pacotes e ajustar o sistema operacional por conta própria. Não tocarei nas configurações e no ambiente do shell no Linux, deixarei isso para o próximo artigo.

apt -y update && apt -y upgrade

Sistema de arquivos WSL 2 e desempenho

Os arquivos dentro da WSL versão 2 são armazenados no disco virtual VHDX, ext4 é usado como o sistema de arquivos. Você pode acessar o WSL rootfs através de um caminho neste formato:

\\wsl$\{DistroName}\

Ou você pode digitar “explorer.exe”. Na CLI e um navegador do Windows será aberto no diretório atual.

A versão 1 da WSL não usava VHDX e tinha fácil acesso ao diretório em que os arquivos do Linux estavam localizados, e a Microsoft desencorajou fortemente a alteração dos arquivos do Linux no Windows. Na nova versão do WSL, o acesso ao FS em um disco virtual é fornecido usando o servidor de arquivos do Plan 9 Filesystem Protocol .



Nas versões anteriores do WSL, havia problemas de desempenho do sistema de arquivos porque as chamadas do sistema eram emuladas pela API do Windows, o acesso ao arquivo era lento e instável. No final de 2019, o WSL 2 mudou sua arquitetura e usou o kernel Linux nativo. A julgar pelo slide da apresentação do youtube de O novo subsistema Windows para arquitetura Linux: um mergulho profundo , o desempenho das operações de disco aumentou de 2 a 5 vezes.

A capacidade máxima do disco é limitada a 256 GB; se esse volume for excedido, você precisará redimensionar, as instruções estão na documentação .

A WSL teve inicialmente problemas ao liberar recursos após o uso da RAM. A versão 19013 resolveu esse problema. Se você executar tarefas exigentes (por exemplo, montar um aplicativo enferrujado), notará que o processo Vmmem estará na parte superior do Gerenciador de Tarefas, mas o consumo de memória diminuiu significativamente nas versões recentes do WSL.

Rede

O nome do host (nome do host) no Linux é obtido do nome do PC no Windows, independentemente do que está escrito em / etc / hostname ou com o comando hostnamectl set-hostname .

Diferente da primeira versão, no WSL 2, a rede funciona através de um comutador virtual Hyper-V:

❯❯ ipconfig.exe | grep IPv4
IPv4 Address. . . . . . . . . . . : 192.168.88.200
IPv4 Address. . . . . . . . . . . : 172.31.160.1
IPv4 Address. . . . . . . . . . . : 172.27.144.1

❯❯ ip -br -4 ad show dev eth0
eth0 UP 172.27.150.196/20
❯❯ ip ro list default
default via 172.27.144.1 dev eth0



Nesse caso, a rede 172.27.144.0/20 é usada no WSL, seu primeiro endereço ( 172.27.144.1 ) é o sistema host do Windows.

No Linux, você pode acessar os serviços de host (em execução no Windows) pela rede, por exemplo, assim:

❯❯ nmap -p 3389 $(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')

O endereço IP do Windows é obtido em /etc/resolv.conf , onde é gerado automaticamente de acordo com as configurações do wsl.conf .

Por outro lado, se você precisar de uma conexão com um soquete Linux a partir de um aplicativo Windows, deverá acessar o endereço IP da WSL. Há uma ressalva - no Linux, o serviço não deve ser executado no host local (127.0.0.1) , mas no endereço 0.0.0.0 . Por exemplo, para aumentar rapidamente o proxy SOCKS5 para o seu VPS, é necessário iniciar o SSH com o parâmetro de encaminhamento dinâmico de porta :

❯❯ ssh -D 0.0.0.0:2299 -N -f proxy.example.com

Depois disso, no aplicativo Windows, por exemplo, Chrome, como o endereço SOCKS5, registre não o host local , mas o endereço WSL, neste caso 172.27.150.196 . A propósito, de uma maneira tão simples de encapsular o tráfego através do VPS no Chrome, torna-se possível usar o acesso aos sites via IPv6.



O Linux sempre altera o endereço IP após uma reinicialização; portanto, em cenários em que você precisa ter um encaminhamento de porta funcionando constantemente e iniciando automaticamente, é necessário procurar uma solução alternativa. Existem muitas maneiras de resolver esse problema, com graus variados de muletas. Você pode ler mais nesta edição no github. Usei o utilitário go-wsl2-host , que implementa o Serviço Windows, que adiciona automaticamente o endereço IP da WSL ao arquivo de hosts do Windows, para que você possa registrar um nome de host como ubuntu.wsl no sistema host e acessar o Linux nele. No entanto, tudo isso muletas e não funciona muito bem, resta esperar a Microsoft para corrigir esses problemas.



UPD Enquanto escrevia este artigo, descobri que havia atualizações (compilação 18945 ), nas quais era possível obter serviços por meio de host local para serviços em execução na WSL. É verdade que ocorreu um erro devido ao qual ele ainda não funcionou para todos, a correção na compilação de agosto é 18970 . Como nem todos recebem atualizações, mesmo se eu fosse um membro do programa Windows Insiders, não ajustei as informações, talvez isso ajude alguém a configurar a interação da rede.

OpenSSH no Windows e serviços de inicialização automática

O Windows 10, como o Windows Server 2019, vem com um fork do OpenSSH , que inclui todos os familiares ssh-keygen, ssh-add, scp e outros utilitários, incluindo ssh-agent e o próprio servidor sshd. O cliente e o servidor podem ser instalados em Aplicativos> Aplicativos e recursos> Gerenciar recursos opcionais, mas a versão do cliente ssh não será a mais recente. Encontrei um bug que não me permitia conectar- se ao host através do host de salto com a opção ProxyJump e verificou-se que esse problema foi corrigido, mas tive que atualizar manualmente o SSH do cliente. Você pode instalar a versão atual do Win32 OpenSSH baixando o zip da seção Versões no github e descompactando-a, por exemplo, em C: \ Arquivos de Programas \ OpenSSH . O software de terceiros ssh.exe (por exemplo, ao usar o modo Desenvolvimento remoto no VSCode) é chamado de $ PATH ( % SYSTEMROOT% \ System32 \ OpenSSH \ ), você precisa alterar a variável de ambiente. As variáveis ​​de ambiente são alteradas através da GUI em Iniciar> Editar as variáveis ​​de ambiente do sistema ( Iniciar> Alterar variáveis ​​de ambiente do sistema ); é necessário colocar uma nova maneira acima da versão antiga.

Como o Systemd não funciona na WSL, há um problema com a inicialização dos serviços com a inicialização do sistema. Existem várias maneiras de configurar o início automático do servidor ssh no WSL, a maneira mais fácil é criar uma tarefa no Agendador de Tarefas, onde você pode especificar o comando de início do servidor. Na Internet, você pode encontrar diferentes instruções de inicialização através dos scripts vbs , ps1 ou bat . O problema com quase todos os métodos é que o gatilho é iniciar o sistema operacional Windows principal, ou seja, se a WSL travar e você precisar reiniciar o sistema ( wsl -t ), o Linux será iniciado sem a execução de um serviço. Quando o Windows é iniciado, a distribuição WSL é iniciada apenas quando é acessada pela primeira vez.

Eu uso o servidor SSH em um laptop dentro da WSL para poder ir remotamente de máquina em máquina. E, devido ao fato de eu usar técnicas de encaminhamento de porta ssh e uma configuração centralizada bem pensada de clientes SSH, posso ir de forma transparente a todos os meus servidores, inserindo um nome de host em vez de endereços. Ou seja, mesmo que você conecte um dos laptops à rede móvel, o daemon autossh se conectará ao host de salto e ainda posso ir ao computador, nenhum NAT será um obstáculo. Portanto, é importante para mim que o sshd esteja sempre ativo.



A única maneira de trabalhar para acessar o SSH no WSL é encaminhar a porta SSH. Isso pode ser feito a partir da própria WSL usando o RemoteForward ou de outro servidor na rede doméstica. Poucas pessoas precisam, e este já é um nível avançado, então darei um comando de trabalho:

❯❯ ssh -R '*:2363:*:22' -N -f mt.example.com

Agora, ao conectar-se ao endereço mt.example.com:2263, você pode acessar diretamente o WSL.

Se você planeja aumentar o servidor SSH na WSL, lembre-se de configurar os parâmetros de inicialização do servidor necessários em / etc / ssh / sshd_config . Para evitar conflitos com a ligação de serviço na porta 22, o servidor OpenSSH no Windows deve ser desativado ou removido completamente se estiver instalado ( Aplicativos> Aplicativos e Recursos> Gerenciar Recursos Opcionais ).

Encaminhamento X

Acabou sendo um momento agradável que no Windows 10 existe um utilitário clip.exe que permite redirecionar o stdout diretamente para a área de transferência do Windows. Isso é conveniente para usar em programas como o tmux e, graças ao encaminhamento do servidor X, o texto também pode ser copiado de hosts remotos. Para que tudo funcione, você sempre deve ter um servidor X em execução no Windows e a variável $ DISPLAY definida corretamente.

Um pouco de teoria chata. Nos sistemas * nix executando o X, existem diferentes tipos de pranchetas ( primária, secundária, prancheta ). No contexto deste artigo, isso não é tão importante, mas é importante para uma compreensão geral do mecanismo de trabalho. Existem dois utilitários (xclip e xsel) para trabalhar com pranchetas no Linux. Ambos os utilitários têm funcionalidade semelhante, no xsel é um pouco maior, mas a funcionalidade básica necessária para encaminhar o conteúdo do buffer é a mesma. Nos aplicativos X, o texto selecionado cai na seleção primária, é inserido com o botão do meio do mouse, em xclip e xsel a seleção primária é usada por padrão.

Por exemplo, para copiar o conteúdo de uma variável para o buffer padrão, você precisa passar stdout para stdin do utilitário xclip, sem parâmetros adicionais:

❯❯ echo -n $DISPLAY | xclip

E para exibir o conteúdo do buffer padrão, execute xclip com a opção -o :

❯❯ xclip -o
172.20.160.1:0

Para que a área de transferência seja redirecionada através do servidor X e os aplicativos gráficos sejam executados no servidor X local, é necessário definir o endereço IP, que é o gateway padrão da WSL, na variável $ DISPLAY . Até agora, nada melhor do que retirá- lo do resolv.conf (que é gerado automaticamente pelo Windows) não foi inventado. Portanto, a maneira mais fácil é registrar a exportação da variável $ DISPLAY no perfil do shell (por exemplo, ~ / .zshrc para zsh).

❯❯ echo "export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0" >> ~/.zshrc



Como servidor X, escolhi o VcXsrv gratuito, ele pode trabalhar com o buffer, possui diferentes modos de exibição de janela e é iniciado a partir da linha de comando com as opções prescritas. Usando o link para gist, você pode ver todas as opções.

Você pode criar uma tarefa de execução automática para o servidor X no Agendador de tarefas desta forma:

Triggers: At startup
Actions: Start a program
____Program: "%ProgramFiles%\VcXsrv\vcxsrv.exe"
____Arguments: -wgl -dpi auto -ac -multiwindow

Chaves ssh

Para que os programas do Windows possam usar chaves SSH (por exemplo, um editor ao trabalhar com um repositório GitHub remoto) e, ao mesmo tempo, não haja uma segunda cópia de chaves no WSL, é melhor gerar chaves no Windows % HOMEPATH% /. Ssh e criar links simbólicos em casa Diretórios WSL.

ssh-keygen -f /mnt/c/Users/${WIN_USER}/.ssh/id_rsa -b 4096
ln -sf /mnt/c/Users/${WIN_USER}/.ssh/id_rsa ${HOME}/.ssh/id_rsa
ln -sf /mnt/c/Users/${WIN_USER}/.ssh/id_rsa.pub ${HOME}/.ssh/id_rsa.pub

Ou, em ~ / .ssh / config, você pode especificar o parâmetro IdentityFile especificando o caminho para as chaves no disco do Windows:

Host *
IdentityFile /mnt/c/Users/${WIN_USER}/.ssh/id_rsa

Se as chaves foram copiadas de algum lugar e as permissões de arquivo não estão definidas corretamente, corrija as permissões:

chmod 600 /mnt/c/Users/${WIN_USER}/.ssh/id_rsa
chmod 644 /mnt/c/Users/${WIN_USER}/.ssh/id_rsa.pub
chmod 700 /mnt/c/Users/${WIN_USER}/.ssh



Portanto, ao configurar ainda mais o acesso por chaves SSH, o usuário é identificado exclusivamente por um conjunto de chaves em um só lugar, ao usar aplicativos Windows e Linux. Agora você pode adicionar a chave pública ao servidor / serviços, para onde precisará ir deste computador. Se houver outros dispositivos na rede doméstica que exijam acesso SSH, será correto copiar sua chave pública para esses servidores ( ssh-copy-id ), mas você não precisará copiar as chaves de um servidor para outro. Como é possível (e necessário) usar o ssh-agent ao trabalhar através do SSH, ao conectar de um servidor a outro, o agente cuida para que a autorização ocorra na chave encaminhada. Para que tudo funcione corretamente e conforme o esperado, você precisa cuidar do arquivo ~ / .ssh / config , no qual você precisa registrar todas as opções necessárias.

Host *
TCPKeepAlive yes
ServerAliveInterval 30
ServerAliveCountMax 3
ForwardAgent yes
AddKeysToAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Qual terminal escolher trabalhar no Linux no Windows

Primeiro, quero fazer uma pequena revisão dos shells de terminal existentes para Windows que podem executar o WSL. Entre os usuários, o processador MobaXterm funcional é popular , o que pode criar várias sessões, inclusive gráficas (WSL, bash / zsh, Mosh, RDP, VNC, etc.), permite criar macros e executar scripts, possui muitas configurações e recursos, agente ssh, encaminhamento automático de porta ssh e ainda possui um servidor ftp / tftp / http interno, mas o produto é de código fechado e, além disso, pago. Hyper é outro emulador de terminal mais moderno que permite executar o shell da WSL, o terminal é construído em HTML / JS / CSS e é expandido usando plug-ins na forma de módulos node.js. ( lista impressionante ). Existem outros terminais que permitem executar o WSL com diferentes graus de muletas ( ConEmu , seu garfo Cmder , WSLtty etc.), mas eu os deixarei sem supervisão.



Mais adiante neste artigo, falaremos sobre o Terminal do Windows , para o qual mudei recentemente, e até agora só estou experimentando emoções positivas. O terminal ainda está na versão beta, mas funciona de maneira bastante estável. Dos recursos atualmente implementados multitab, separação de painéis (divisão), perfis personalizados de conexões de terminais, esquemas de cores, bem, não há mais nada a listar. Mas essa funcionalidade é suficiente, eu até gosto que o software não seja sobrecarregado de supérfluo - como se os desenvolvedores aderissem ao princípio do KISS .

O terminal evoluiu do projeto Windows Console (ConPTY), aprendendo a suportar sequências ANSI / VT, cores reais RGB de 24 bits e UTF-8. Seguindo os links ( início , continuação ) em Habré, uma tradução maravilhosa de uma série de postagens no blog da Linha de Comando do Windows: Inside the Windows Console , que conta sobre a história da criação de terminais, padrões relacionados à transferência de seqüências de escape, páginas de código, unicode, o surgimento de emuladores de terminal e no futuro já é uma evolução da linha de comando do Windows. Tecnólogos podem estar interessados. A equipe de engenharia que trabalha nesse projeto de código-fonte aberto mantém o devlog da Linha de Comandos do Windows , que é mais do que totalmente dedicado ao WSL e ao Windows Terminal. Eu nunca teria acreditado antes naquele momento que estaria assistindo com interesse o desenvolvimento de produtos MS, mas o que eles fazem como parte do desenvolvimento de WSL, Terminal e VSCode realmente merece respeito. Como o desenvolvimento da WSL começou, é descrito no Microsoft Open Source Stories (há uma tradução em Habré). A propósito, a Microsoft é um membro de platina da Linux Foundation desde 2016.

Instale e configure o Terminal do Windows

Você pode instalar o Windows Terminal na Windows Store ou baixando o binário da seção Versões no github do projeto, todas as informações, instruções e perguntas frequentes relevantes também estão disponíveis. O terminal requer pelo menos uma versão do Windows 1903 e compilação 18362 . É preferível instalar através da Windows Store, pois é mais fácil atualizar neste caso, diretamente da loja. As atualizações são emitidas regularmente; um roteiro da primeira versão do terminal foi definido no github. No momento, todos os recursos da versão 1 já foram implementados (de acordo com o plano, para implementar todas as melhorias até o final de 2019), depois de alguns meses de trabalho na correção de bugs e em abril de 2020 está planejado o lançamento oficial do Terminal v1.0. É bom que a MS esteja agora no github, seu software aprendeu a mostrar logs, erros inteligíveis e quaisquer problemas são facilmente pesquisados ​​no Google.



Ainda não existem muitas configurações no terminal, mas são suficientes para um trabalho confortável, o produto está em desenvolvimento ativo, existe no github onde os usuários podem criar uma solicitação de recurso ou um relatório de bug. Os desenvolvedores participam da discussão de problemas com os usuários, geralmente oferecendo soluções alternativas quando um bug é descoberto.



A configuração é armazenada no formato json, depois de salva, é aplicada imediatamente. Isso é conveniente apenas porque você pode aplicar boas práticas para gerenciar a configuração do ambiente de trabalho - eu armazeno todas as configurações do Linux no repositório git, no Windows eu uso apenas o VSCode da ferramenta de trabalho, que pode sincronizar a configuração via github gist e salvar a configuração da área de trabalho local separadamente em dotfiles . Portanto, o Terminal se move na mesma direção, usando as mesmas teclas de atalho e o formato de configuração que o VSCode. A propósito, editar uma configuração é conveniente através do VSCode, especialmente se você já usa este excelente editor da MS. O arquivo de configuração do terminal já contém muitas configurações padrão e o editor correto permite que você veja todas as opções com uma descrição das opções de chave e valor do esquema (isso é especialmente conveniente quando o projeto ainda não possui documentação completa). Além disso, todos os chips IDE estão disponíveis na forma de preenchimento automático, intellisense, verificação de sintaxe, formatação, etc.



A documentação para desenvolvedores está disponível aqui , mas aqui está uma pequena página de documentação para usuários por enquanto. Uma página separada é dedicada às configurações gravadas no arquivo de configuração json. A partir daí, você pode descobrir que estruturalmente as configurações são divididas em:

• Global (perfil padrão, tamanho inicial da janela do terminal, tema etc.)
• Key Bindings
• Perfis (configurações específicas para cada terminal)
• Esquemas (esquemas de cores)

Existem perfis dinâmicos, que aparecem automaticamente na configuração e têm a propriedade de origem . WSL Azure Cloud Shell. WSL (, Ubuntu), GUID , source , commandline wsl -d {DistroName} .

- , . :

• Fira Code
• Hack

Eu uso a fonte do programador Fira Code no terminal e no editor. Ele suporta a maioria dos caracteres usados ​​no design de programas CLI e interfaces de console, ligaduras e também não há problemas em exibir emojis no terminal.



A fonte é instalada no Windows usando o instalador de fontes do SO. Para fazer isso, baixe a versão mais recente da fonte que você gosta do arquivo de versões do github e instale manualmente a fonte no sistema.

Você pode visualizar o nome da fonte (configurando o terminal fontFace ) durante a instalação ou posteriormente no aplicativo Mapa de Caracteres ( Tabela de Símbolos ). Além disso, em Iniciar -> Configurações -> Personalização -> Fontes você pode ver como a fonte é renderizada em modos diferentes e ao mesmo tempo verificar como as ligaduras são desenhadas.

Conclusão

O resultado foi um artigo muito longo, em um só lugar, todas as informações relevantes sobre instalação, configuração e uso do Windows Terminal em conjunto com a WSL são coletadas. No futuro, quero escrever artigos sobre ZSH e tmux da mesma maneira e escrever minha experiência de implantação de configurações na VM e sincronização de arquivos de ponto entre hosts. Tudo está dentro da estrutura de automação de rede doméstica, mas será útil para desenvolvedores / devops / engenheiros de sistema. Outro tópico não resolvido foi o lançamento do Docker no WSL 2 , mas não preciso executar o Docker em um computador pessoal, pois há um servidor dedicado para isso.

Espero que ninguém se arrependa de ter lido o artigo e divulgado novos conhecimentos. Se alguém tiver algo a acrescentar, vamos compartilhar nossos pensamentos nos comentários. Se você tiver algum comentário sobre o texto, escreva para o PM, quero manter este guia atualizado.

Referências

• Anúncio do WSL 2 (devblogs.microsoft.com)
• O WSL 2 já está disponível no Windows Insiders (devblogs.microsoft.com)
• Recuperação de memória no subsistema Windows para Linux 2 (devblogs.microsoft.com)
• Configurando automaticamente o WSL (devblogs.microsoft.com)
• wsl2-tutorial (github.com)
• Roteiro do Terminal v1.0 (github.com)
• Editando as configurações JSON do terminal do Windows (github.com)