Il y a des gens qui passent la majeure partie de leur temps de travail dans la console, il y a ceux qui utilisent le terminal si nécessaire, exécutant quelque chose selon les instructions. Mais je pense que chaque spécialiste informatique, qu'il soit développeur, administrateur système, ingénieur réseau ou même développeur yaml senior, utilise l'interface de ligne de commande. Tout le monde ne pense pas à améliorer l'environnement de travail dans la CLI et à augmenter la productivité dans le terminal. Je voudrais partager mon expérience dans la configuration de l'environnement pour travailler avec Linux à partir de Windows.



Dans cet article, vous apprendrez quels outils et terminaux sont actuellement utilisés pour exécuter des applications Linux sur Windows 10. Nous parlerons de WSL 2 et de Windows Terminal , qui gagne de plus en plus en popularité auprès des utilisateurs qui ont besoin de Linux pour fonctionner. Étant donné que la plupart de mes cas d'utilisation sont liés à la connexion à distance via SSH, la plupart des informations seront pertinentes pour les cas de connexions à distance, avec toutes les fonctionnalités associées à cela (transfert des clés ssh via l'agent ssh, transfert du serveur X, gestion des connexions, etc.) )

Attention! Sous la coupe beaucoup d'images et de gif rétrécis, mais parfois volumineux, il est recommandé d'ouvrir l'article si vous avez un accès approprié à Internet. Passez sous le chat si vous êtes intéressé à exécuter des utilitaires Linux sous Windows, à optimiser votre travail dans l'environnement CLI, ou si vous aimez tout simplement les textes techniques et les terminaux couleur. J'ai essayé d'éclaircir le texte avec des captures d'écran et des captures d'écran du terminal, afin qu'il ne soit pas ennuyeux.

Présentation

À la fois sur mon ordinateur portable personnel et professionnel, le seul système d'exploitation que j'ai est Windows 10, et cette année, je suis finalement passé à utiliser uniquement WSL au lieu de VM / dualboot / Cygwin / MinGW. Maintenant, mon terminal par défaut est le shell WSL local, où je peux exécuter presque toutes les tâches, comme sous Linux natif. De plus, le mini-serveur Intel NUC s'exécute sur le réseau domestique, sur lequel Proxmox est déployé avec des conteneurs LXC et KVM, dans lequel Docker tourne. Je vais sur toutes les VM via SSH, avec les clés du répertoire Windows. Beaucoup de temps dans l'activité professionnelle se déroule dans la CLI, avec le même serveur et le même réseau. Par conséquent, il y a toujours un désir de gérer des outils pour un travail plus confortable dans le terminal, et dans Windows, il y avait toujours des problèmes avec cela. Mais maintenant tout change.



Cet article et les suivants sont plus axés sur les passionnés qui recherchent de nouvelles solutions et veulent pomper leur coquille. Mais pour les débutants, quelque chose devrait être intéressant, bien que l'article se soit avéré assez profondément immergé dans le sujet et suggère que le lecteur ait des connaissances fondamentales sous Linux. Toutes les informations sont collectées sur la base d'une expérience personnelle avec WSL, un terminal, ainsi que d'une pagination sans fin des problèmes de débordement de pile et de Github dans le processus d'amélioration constante des configurations et de recherche d'outils pratiques pour le travail.

Sous-système Windows pour Linux (WSL) 2

Il existe plusieurs articles normaux sur WSL sur Internet et sur Habr ( une fois un article sur l'installation / la configuration de WSL avec un serveur X, deux notes sur WSL 2, trois articles sur le développement Python dans VSCode avec WSL) qui décrivent l'installation et la configuration du système. Cependant, toutes les actions d'installation ne sont pas déjà pertinentes, ainsi que les restrictions avec pièges deviennent moins. Je ne m'attarderai pas sur l'installation en détail, les instructions pour installer la (seconde) version actuelle de WSL sont sur le site Web de Microsoft , et vous pouvez également trouver de courts tutoriels sur Internet.



Maintenant, WSL est toujours en développement actif et récemment ( juin 2019 ) une nouvelle version de WSL 2 a été publiée, qui n'est actuellement disponible que pour les nouvelles versions de Windows pour les membres de Windows Insiders. Si possible, je vous conseille de mettre immédiatement à niveau WSL vers la version 2, car cela a amélioré le travail des appels système, le travail avec le réseau, le FS, et en général, il est construit sur une architecture différente et, selon certaines données, donne une augmentation de 20 fois la vitesse par rapport à la première version.

Vous pouvez voir la version de Windows 10 et la build du système d'exploitation dans Démarrer -> Paramètres -> Système -> À propos , pour installer WSL 2, vous avez besoin de Windows 1903 et au moins de la version de build 18917 . Si vous n'êtes pas membre du programme Windows Insider , les mises à jour n'arriveront probablement pas avant une version stable. Donc, si vous souhaitez mettre à niveau vers la dernière version, vous pouvez activer l'accès rapide ( rapide ) dans Démarrer -> Paramètres -> Mise à jour et sécurité -> Programme Windows Insider , mettre à jour et désactiver d'autres mises à jour. Il convient de noter que des mises à jour non encore testées en masse seront installées, ce qui peut affecter la stabilité.

Il convient de garder à l'esprit qu'avant la version 18995, WSL a un bogue lors de l'utilisation de fichiers sur des disques Windows montés, exprimé sous la forme d'une erreur d'entrée / sortie, le redémarrage de WSL uniquement ( wsl --shutdown dans PowerShell) étant utile. En général, il existe de nombreux bogues corrigés qui sont toujours présents dans WSL version 1 (qui est définie par défaut) et les distributions non prévisualisées de Windows. Si les mises à jour de votre système d'exploitation sont réglementées par les politiques de l'entreprise, les dernières mises à jour n'arriveront probablement pas et vous devez en tenir compte. Sur l'un des ordinateurs portables, j'ai construit 18956 et il n'y a pas de mises à jour, malgré le fait que l'option Fast est sélectionnée dans les paramètres du programme Insider. Un système propre a été installé sur un autre ordinateur portable il y a quelques mois, et des mises à jour arrivent régulièrement et sont installées.

Installer WSL 2

WSL nécessite que Hyper-V soit activé car les distributions Linux s'exécutent sur des machines virtuelles légères utilisant la virtualisation Hyper-V.



Ensuite, je donnerai une brève instruction d'installation à partir de la distribution CLI PowerShell de WSL en utilisant Kali Linux comme exemple). Si vous préférez Ubuntu ou une autre distribution Linux disponible, remplacez le lien et les noms par ceux appropriés.

Vérifiez la version de build de Windows:

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

Activez les composants VirtualMachinePlatform et Microsoft-Windows-Subsystem-Linux:

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

Redémarrer
Ensuite, installez la distribution à partir du Microsoft Store ( https://aka.ms/wslstore ) ou continuez à exécuter dans PowerShell:

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

Lancez la console WSL (la distribution doit apparaître dans le menu Démarrer, recherchez par le nom de la distribution), attendez l'invitation pour installer un nouvel utilisateur, fermez la console.

Maintenant, la distribution devrait apparaître dans la liste si elle est exécutée dans PowerShell:

wsl -l -v

Si nécessaire, convertissez la distribution au format WSL version 2:

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

Faites de root l'utilisateur par défaut (facultatif):

kali config --default-user root

Si vous obtenez l'erreur "Une tentative de connexion a échoué parce que la partie connectée n'a pas répondu correctement après un certain temps, ou la connexion établie a échoué parce que l'hôte connecté n'a pas répondu." , Alors vous avez une version dans laquelle la suivante (déjà corrigée) dans les versions récentes) bug. Comme d'habitude, il existe une solution de contournement , ou utilisez la distribution Ubuntu, je n'ai eu aucun problème avec elle sur la même version pas la dernière de la build.

Si nécessaire, vous pouvez déplacer le disque virtuel WSL vers une autre partition (différente de C :) selon les instructions . Il vaut mieux le faire tout de suite, car tout ne se passe pas bien.

Avertissement sur la sécurité . Dans WSL et sur d'autres serveurs Linux du réseau domestique, je ne démarre aucun système critique, et il n'y a pas d'autres utilisateurs (sauf moi) sur le réseau, donc je vais rooter presque partout, avec l'authentification ssh via des clés. Je sais que ce n'est pas la meilleure pratique, mais je parle d'un environnement de développement personnel et je ne vois pas l'intérêt de créer un utilisateur non root. Les problèmes de sécurité ne seront pas pris en compte dans cet article, je vais en parler un jour (sur la façon d'organiser l'interaction des services via TLS avec un renouvellement de certificat centralisé dans un réseau domestique; sur la synchronisation ~ / .ssh / config entre les serveurs, le transfert ports et clés, etc.).

Configuration WSL

À partir de la build 17093 , le fichier de configuration WSL principal se trouve sur le système de distribution FS à /etc/wsl.conf , il décrit les paramètres qui seront appliqués à chaque démarrage de la distribution:

• Montage automatique - montage automatique des lecteurs Windows
• Réseau - générer des fichiers resolv.conf, des hôtes
• Interop - démarrez les processus Windows et ajoutez Windows $ PATH à Linux $ PATH

Initialement, WSL se passe de cette configuration, elle doit être enregistrée manuellement:

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

[network]
generateHosts = true
generateResolvConf = true

[interop]
enabled = true
appendWindowsPath = true

Certains paramètres sont utilisés avec la valeur par défaut et avec /etc/wsl.conf vide, mais pour le bon fonctionnement avec les fichiers, vous devez enregistrer au moins le paramètre options , sinon les fichiers Windows auront les autorisations 777 et cela ne peut pas être modifié à partir de Linux.



Vous pouvez redémarrer la distribution à partir de PowerShell avec la commande:

wsl -t kali-linux

Après cela, vous pouvez mettre à jour les packages et régler vous-même le système d'exploitation. Je ne toucherai pas aux paramètres du shell et à l'environnement sous Linux, je laisserai cela pour le prochain article.

apt -y update && apt -y upgrade

Système de fichiers WSL 2 et performances

Les fichiers à l'intérieur de WSL version 2 sont stockés sur le disque virtuel VHDX, ext4 est utilisé comme système de fichiers. Vous pouvez accéder à rootfs WSL via un chemin d'accès au format suivant:

\\wsl$\{DistroName}\

Ou, vous pouvez taper "explorer.exe". Dans la CLI et un navigateur Windows s'ouvrira dans le répertoire actuel.

WSL version 1 n'utilisait pas VHDX et avait un accès facile au répertoire où se trouvaient les fichiers Linux, et Microsoft déconseillait fortement de changer les fichiers Linux de Windows. Dans la nouvelle version de WSL, l'accès au FS sur un disque virtuel est fourni à l'aide du serveur de fichiers Plan 9 Filesystem Protocol .



Dans les versions précédentes de WSL, il y avait des problèmes de performances du système de fichiers car les appels système étaient émulés via l'API Windows, l'accès aux fichiers était lent et instable. Fin 2019, WSL 2 a changé son architecture et utilisé le noyau Linux natif. À en juger par la diapositive de la présentation youtube de Le nouveau sous-système Windows pour l'architecture Linux: une plongée profonde , les performances des opérations sur disque ont augmenté de 2 à 5 fois.

La capacité maximale du disque est limitée à 256 Go, si ce volume est dépassé, vous devrez faire un redimensionnement, les instructions sont dans la documentation .

WSL a initialement rencontré des problèmes de libération de ressources après avoir utilisé la RAM. La version 19013 a résolu ce problème. Si vous exécutez des tâches exigeantes (par exemple, assembler une application Rust ), vous remarquerez que le processus Vmmem se trouvera en haut du Gestionnaire des tâches, mais la consommation de mémoire a considérablement diminué dans les versions récentes de WSL.

Réseau

Le nom d'hôte (hostname) sous Linux est tiré du nom du PC sous Windows, indépendamment de ce qui est écrit dans / etc / hostname ou avec la commande hostnamectl set-hostname .

Contrairement à la première version, dans WSL 2, le réseau fonctionne via un commutateur Hyper-V virtuel:

❯❯ 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



Dans ce cas, le réseau 172.27.144.0/20 est utilisé sous WSL, sa première adresse ( 172.27.144.1 ) est le système hôte Windows.

Depuis Linux, vous pouvez accéder aux services hôtes (fonctionnant sous Windows) sur le réseau, par exemple, comme ceci:

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

L'adresse IP Windows provient de /etc/resolv.conf , où elle est générée automatiquement en fonction des paramètres wsl.conf .

Inversement, si vous avez besoin d'une connexion à un socket Linux à partir d'une application Windows, vous devez accéder à l'adresse IP de WSL. Il y a une mise en garde - sous Linux, le service ne doit pas être exécuté sur localhost (127.0.0.1) , mais sur l'adresse 0.0.0.0 . Par exemple, pour augmenter rapidement le proxy SOCKS5 sur votre VPS, vous devez démarrer SSH avec le paramètre de redirection de port dynamique :

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

Après cela, dans l'application Windows, par exemple Chrome, en tant qu'adresse SOCKS5, enregistrez non pas l' hôte local , mais l'adresse WSL, dans ce cas 172.27.150.196 . Soit dit en passant, d'une manière si simple de tunneliser le trafic via VPS dans Chrome, il devient possible d'utiliser l'accès aux sites via IPv6.



Linux changera son adresse IP après un redémarrage à chaque fois, donc dans les scénarios où vous avez besoin d'un transfert de port fonctionnant constamment et démarrant automatiquement, vous devez rechercher une solution de contournement. Il existe de nombreuses façons de résoudre ce problème, à divers degrés de béquilles, vous pouvez en lire plus dans ce numéro sur github. J'ai utilisé l'utilitaire go-wsl2-host , qui implémente le service Windows, qui ajoute automatiquement l'adresse IP WSL au fichier d'hôtes Windows, afin que vous puissiez enregistrer un nom d'hôte tel que ubuntu.wsl sur le système hôte et accéder à Linux sur celui-ci. Cependant, toutes ces béquilles et ne fonctionnent pas très bien, il reste à attendre que Microsoft corrige ces problèmes.



UPD Pendant que j'écrivais cet article, j'ai découvert qu'il y avait des mises à jour (build 18945 ), dans lesquelles il était possible de passer des services via localhost aux services s'exécutant en WSL. Certes, il s'est avéré qu'il y avait un bogue en raison duquel il ne fonctionnait toujours pas pour tout le monde, le correctif dans la version d'août est 18970 . Étant donné que tout le monde ne reçoit pas de mises à jour, même si j'étais membre du programme Windows Insiders, je n'ai pas ajusté les informations, cela aidera peut-être quelqu'un à configurer l'interaction réseau.

OpenSSH sur Windows et services de démarrage automatique

Windows 10, comme Windows Server 2019, est livré avec un fork OpenSSH , qui comprend tous les utilitaires familiers ssh-keygen, ssh-add, scp et d'autres, y compris ssh-agent et le serveur sshd lui-même. Le client et le serveur peuvent être installés via Applications> Applications et fonctionnalités> Gérer les fonctionnalités facultatives, mais la version du client ssh ne sera pas la dernière. J'ai rencontré un bogue qui ne me permettait pas de me connecter à l'hôte via l'hôte de saut avec l'option ProxyJump et il s'est avéré que ce problème était résolu, mais j'ai dû mettre à jour manuellement le client SSH. Vous pouvez installer la version actuelle de Win32 OpenSSH en téléchargeant zip depuis la section Releases sur le github et en la décompressant, par exemple, dans C: \ Program Files \ OpenSSH . Le logiciel tiers ssh.exe (par exemple, lorsque vous utilisez le mode de développement à distance dans VSCode) est appelé à partir de $ PATH ( % SYSTEMROOT% \ System32 \ OpenSSH \ ), vous devez modifier la variable d'environnement. Les variables d'environnement sont modifiées via l'interface graphique dans Démarrer> Modifier les variables d'environnement système ( Démarrer> Modifier les variables d'environnement système ), là, vous devez mettre une nouvelle façon au-dessus de l'ancienne version.

Puisque Systemd ne fonctionne pas dans WSL, il y a un problème avec le démarrage des services avec le démarrage du système. Il existe plusieurs façons de configurer le démarrage automatique du serveur ssh dans WSL, la manière la plus simple consiste à créer une tâche dans le Planificateur de tâches, où vous pouvez spécifier la commande de démarrage du serveur. Sur Internet, vous pouvez trouver différentes instructions de démarrage via les scripts vbs , ps1 ou bat . Le problème avec presque toutes les méthodes est que le déclencheur est de démarrer le système d'exploitation Windows principal, c'est-à-dire que si WSL se bloque et que vous devez redémarrer le système ( wsl -t ), Linux démarrera sans exécution de service. Lorsque Windows démarre, la distribution WSL démarre uniquement lors de son premier accès.

J'utilise le serveur SSH sur un ordinateur portable à l'intérieur de WSL afin de pouvoir aller à distance d'une machine à l'autre. Et, du fait que j'utilise des techniques de transfert de port ssh et une configuration centralisée bien pensée des clients SSH, je peux accéder en toute transparence à tous mes serveurs, en entrant un nom d'hôte au lieu d'adresses. Autrement dit, même si vous connectez l'un des ordinateurs portables au réseau mobile, le démon autossh se connectera à l'hôte de saut et je peux toujours aller à l'ordinateur, aucun NAT ne sera un obstacle. Par conséquent, il est important pour moi que sshd soit toujours actif.



La seule façon de travailler pour accéder à SSH dans WSL est de transférer le port SSH. Cela peut être fait à partir du WSL lui-même à l'aide de RemoteForward , ou à partir d'un autre serveur sur le réseau domestique. Peu de gens en ont besoin, et c'est déjà un niveau avancé, donc je vais juste donner une commande fonctionnelle:

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

Maintenant, lorsque vous vous connectez à l'adresse mt.example.com:2263, vous pouvez accéder directement au WSL.

Si vous prévoyez d'augmenter le serveur SSH dans WSL, vous devez vous rappeler de configurer les paramètres de démarrage du serveur nécessaires dans / etc / ssh / sshd_config . Pour éviter tout conflit avec la liaison de service sur le port 22, le serveur OpenSSH sous Windows doit être désactivé ou supprimé complètement s'il est installé ( Applications> Applications et fonctionnalités> Gérer les fonctionnalités facultatives ).

Transfert X

Il s'est avéré être un moment agréable que dans Windows 10, il existe un utilitaire clip.exe qui vous permet de rediriger stdout directement vers le presse-papiers de Windows. Ceci est pratique à utiliser dans des programmes tels que tmux, et grâce au transfert du serveur X, le texte peut également être copié à partir d'hôtes distants. Pour que tout fonctionne, vous devez toujours avoir un serveur X fonctionnant sous Windows et la variable $ DISPLAY définie correctement.

Une petite théorie ennuyeuse. Sur les systèmes * nix exécutant X, il existe différents types de presse-papiers ( primaire, secondaire, presse-papiers ), dans le contexte de cet article, ce n'est pas si important, mais il est important pour une compréhension générale du mécanisme de travail. Il existe deux utilitaires (xclip et xsel) pour travailler avec les presse-papiers sous Linux. Les deux utilitaires ont des fonctionnalités similaires, dans xsel, il est légèrement plus grand, mais les fonctionnalités de base nécessaires pour transmettre le contenu du tampon sont les mêmes. Dans les applications X, le texte sélectionné tombe dans la sélection principale, il est inséré avec le bouton central de la souris, dans xclip et xsel la sélection principale est utilisée par défaut.

Par exemple, pour copier le contenu d'une variable dans le tampon par défaut, vous devez passer stdout à stdin de l'utilitaire xclip, sans paramètres supplémentaires:

❯❯ echo -n $DISPLAY | xclip

Et pour afficher le contenu du tampon par défaut, exécutez xclip avec le commutateur -o :

❯❯ xclip -o
172.20.160.1:0

Pour que le presse-papiers soit redirigé via le serveur X et que les applications graphiques s'exécutent sur le serveur X local, vous devez définir l'adresse IP, qui est la passerelle par défaut pour WSL, dans la variable $ DISPLAY . Jusqu'à présent, rien de mieux que de le prendre à partir de resolv.conf (qui est généré automatiquement par Windows) n'a pas été inventé. Par conséquent, le moyen le plus simple consiste à enregistrer l'exportation de la variable $ DISPLAY dans le profil de shell (par exemple, ~ / .zshrc pour zsh).

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



En tant que serveur X, j'ai choisi le VcXsrv gratuit, il peut fonctionner avec le tampon, a différents modes d'affichage de fenêtre et est lancé à partir de la ligne de commande avec les options prescrites. En utilisant le lien pour résumer, vous pouvez voir toutes les options.

Vous pouvez créer une tâche d'exécution automatique pour le serveur X dans le Planificateur de tâches comme ceci:

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

Touches SSH

Pour que les programmes de Windows puissent utiliser des clés SSH (par exemple, un éditeur lors de l'utilisation d'un référentiel GitHub distant), et en même temps qu'il n'y ait pas de deuxième copie de clés dans WSL, il est préférable de générer des clés dans Windows % HOMEPATH% /. Ssh et de créer des liens symboliques à la maison Répertoires 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, dans ~ / .ssh / config, vous pouvez spécifier le paramètre IdentityFile en spécifiant le chemin d'accès aux clés sur le disque Windows:

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

Si les clés ont été copiées quelque part et que les autorisations de fichier ne sont pas définies correctement, corrigez les autorisations:

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



Ainsi, lors de la définition d'un accès supplémentaire par des clés SSH, l' utilisateur est identifié de manière unique par un ensemble de clés en un seul endroit, à la fois lors de l'utilisation d'applications Windows et Linux. Vous pouvez maintenant ajouter la clé publique au serveur / services, où vous devrez vous rendre depuis cet ordinateur. S'il y a d'autres périphériques sur le réseau domestique qui nécessitent un accès SSH, alors il sera correct de copier votre clé publique sur ces serveurs ( ssh-copy-id ), mais vous n'avez pas besoin de copier les clés d'un serveur sur un autre. Puisqu'il est possible (et nécessaire) d'utiliser ssh-agent lors de l'utilisation de SSH, lors de la connexion d'un serveur à un autre, l'agent veille à ce que l'autorisation se produise sur la clé transférée. Pour que tout fonctionne correctement et comme prévu, vous devez prendre soin du fichier ~ / .ssh / config , dans lequel vous devez enregistrer toutes les options nécessaires.

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

Quel terminal choisir pour travailler sous Linux sur Windows

Tout d'abord, je veux faire un petit examen des shells de terminaux existants pour Windows qui peuvent exécuter WSL. Parmi les utilisateurs, le processeur fonctionnel MobaXterm est populaire , qui peut créer diverses sessions, y compris des sessions graphiques (WSL, bash / zsh, Mosh, RDP, VNC, etc.), vous permet de créer des macros et d'exécuter des scripts, possède de nombreux paramètres et fonctionnalités, agent ssh, redirection de port ssh autorun, et a même un serveur ftp / tftp / http intégré, mais le produit est en source fermée et, en outre, payant. Hyper est un autre émulateur de terminal plus moderne qui vous permet d'exécuter le shell WSL, le terminal est construit sur HTML / JS / CSS et est développé à l'aide de plug-ins sous la forme de modules node.js ( liste impressionnante ). Il existe d'autres terminaux qui vous permettent d'exécuter WSL avec différents degrés de béquilles ( ConEmu , sa fourche Cmder , WSLtty , etc.), mais je les laisserai sans surveillance.



Plus loin dans cet article, nous parlerons du terminal Windows , sur lequel j'ai récemment basculé, et jusqu'à présent, je ne ressens que des émotions positives. Le terminal est toujours en version bêta, mais il fonctionne de manière assez stable. Parmi les fonctionnalités multi-onglets actuellement implémentées, la séparation des panneaux (séparation), les profils personnalisés des connexions des terminaux, les schémas de couleurs, eh bien, il n'y a plus rien à énumérer. Mais cette fonctionnalité est bien suffisante, j'aime même que le logiciel ne soit pas surchargé de superflu - comme si les développeurs adhéraient au principe KISS .

Le terminal a évolué à partir du projet Windows Console (ConPTY), apprenant à prendre en charge les séquences ANSI / VT, les couleurs vraies RVB 24 bits et UTF-8. En suivant les liens ( début , suite ) sur Habré, une merveilleuse traduction d'une série de billets de blog en ligne de commande Windows: Inside the Windows Console , qui raconte l'histoire de la création de terminaux, les normes liées au transfert de séquences d'échappement, les pages de codes, l'unicode, l'émergence d'émulateurs de terminaux et dans le futur déjà une évolution de la ligne de commande windows. Les technologues peuvent être intéressés. L'équipe d'ingénierie travaillant sur ce projet opensource gère le devlog de la ligne de commande Windows , qui est plus que entièrement dédié à WSL et Windows Terminal. Je n'aurais jamais cru avant ce moment que je regarderais avec intérêt le développement des produits MS, mais ce qu'ils font dans le cadre du développement de WSL, Terminal et VSCode mérite vraiment le respect. Comment le développement de WSL a commencé, est décrit dans Microsoft Open Source Stories (il y a une traduction sur Habré). Soit dit en passant, Microsoft est membre platine de la Linux Foundation depuis 2016.

Installer et configurer le terminal Windows

Vous pouvez installer Windows Terminal à partir du Windows Store , ou en téléchargeant le binaire à partir de la section Versions du github du projet, toutes les informations, instructions et FAQ pertinentes sont également présentes. Le terminal nécessite au moins une version de Windows 1903 et une version 18362 . Il est préférable d'installer via le Windows Store, car il est plus facile de mettre à jour dans ce cas, directement depuis le magasin. Des mises à jour sont publiées régulièrement; une feuille de route de la première version du terminal a été mise en place sur le github. Pour le moment, toutes les fonctionnalités de la version 1 ont déjà été implémentées (selon le plan, pour implémenter toutes les améliorations d'ici fin 2019), puis quelques mois de travail sur la correction des bugs et en avril 2020 la sortie officielle du Terminal v1.0 est prévue. C'est bien que MS soit maintenant sur le github, leur logiciel a appris à afficher les journaux, les erreurs intelligibles et tout problème est facilement googlé.



Il n'y a pas encore beaucoup de paramètres dans le terminal, mais ils sont suffisants pour un travail confortable, le produit se développe activement, il y a sur github où les utilisateurs peuvent créer une demande de fonctionnalité ou un rapport de bogue. Les développeurs participent à la discussion des problèmes avec les utilisateurs, proposant souvent des solutions de contournement lorsqu'un bogue est découvert.



La configuration est stockée au format json, après avoir été enregistrée, elle est appliquée immédiatement. Ceci est pratique, ne serait-ce que parce que vous pouvez appliquer les bonnes pratiques pour gérer la configuration de l'environnement de travail - je stocke toutes les configurations Linux dans le référentiel git, sur Windows j'utilise uniquement VSCode à partir de l'outil de travail, qui peut synchroniser la configuration via github gist et enregistrer la configuration de l'espace de travail local séparément dans des fichiers de points . Ainsi, Terminal se déplace dans la même direction, en utilisant les mêmes touches de raccourci et le format de configuration que VSCode. Soit dit en passant, l'édition d'une configuration est pratique via VSCode, surtout si vous utilisez déjà cet excellent éditeur de MS. Le fichier de configuration du terminal contient déjà de nombreux paramètres par défaut, et l'éditeur approprié vous permet de voir toutes les options avec une description des options de clé et de valeur du schéma (ceci est particulièrement pratique lorsque le projet n'a pas encore de documentation complète). De plus, toutes les puces IDE sont disponibles sous forme d'auto-complétion, d'intellisense, de vérification de syntaxe, de formatage, etc.



La documentation pour les développeurs est disponible ici , mais voici une petite page de documentation pour les utilisateurs pour l'instant. Une page distincte est consacrée aux paramètres qui sont écrits dans le fichier de configuration json. De là, vous pouvez découvrir que, structurellement, les paramètres sont divisés en:

• Global (profil par défaut, taille initiale de la fenêtre du terminal, thème, etc.)
• Liaisons de touches
• Profils (paramètres spécifiques à chaque terminal)
• Schémas (schémas de couleurs)

Les profils dynamiques existent, ils apparaissent automatiquement dans la configuration et ont la propriété source . WSL Azure Cloud Shell. WSL (, Ubuntu), GUID , source , commandline wsl -d {DistroName} .

- , . :

• Fira Code
• Hack

J'utilise la police de programmation Fira Code à la fois dans le terminal et dans l'éditeur. Il prend en charge la plupart des caractères utilisés dans la conception des programmes CLI et des interfaces de console, des ligatures, et il n'y a aucun problème avec l'affichage des emojis dans le terminal.



La police est installée sur Windows à l'aide du programme d'installation de polices du système d'exploitation. Pour ce faire, téléchargez la dernière version de la police que vous aimez dans l'archive des versions de github et installez manuellement la police dans le système.

Vous pouvez afficher le nom de la police (définition de la police fontFace du terminal ) pendant l'installation ou ultérieurement dans l'application Table des caractères ( Table des symboles ). De plus, dans Démarrer -> Paramètres -> Personnalisation -> Polices vous pouvez voir comment la police est rendue dans différents modes, et en même temps vérifier comment les ligatures sont dessinées.

Conclusion

Le résultat a été un article très long, en un seul endroit toutes les informations pertinentes sur l'installation, la configuration et l'utilisation de Windows Terminal en conjonction avec WSL sont collectées. À l'avenir, je veux écrire des articles sur ZSH et tmux de la même manière, et écrire mon expérience de déploiement de configurations sur VM et de synchronisation de fichiers dot entre hôtes. Tout est dans le cadre de l'automatisation du réseau domestique, mais il sera utile pour les développeurs / développeurs / ingénieurs système. Un autre sujet non résolu a été le lancement de Docker dans WSL 2 , mais je n'ai pas besoin d'exécuter Docker sur un ordinateur personnel, car il existe un serveur dédié pour cela.

J'espère que personne n'a regretté d'avoir lu l'article et apporté de nouvelles connaissances. Si quelqu'un a quelque chose à ajouter, partageons nos réflexions dans les commentaires. Si vous avez des commentaires sur le texte, écrivez au PM, je veux garder ce guide à jour.

Les références

• Annonce de WSL 2 (devblogs.microsoft.com)
• WSL 2 est désormais disponible dans Windows Insiders (devblogs.microsoft.com)
• Récupération de mémoire dans le sous-système Windows pour Linux 2 (devblogs.microsoft.com)
• Configuration automatique de WSL (devblogs.microsoft.com)
• wsl2-tutorial (github.com)
• Feuille de route du terminal v1.0 (github.com)
• Modification des paramètres JSON du terminal Windows (github.com)