- PVSM.RU - https://www.pvsm.ru -

Настройка окружения в CLI. WSL – Windows Terminal

Есть люди, которые большинство рабочего времени проводят в консоли, есть те, кто пользуются терминалом при необходимости, запуская что-то по инструкциям. Но я думаю, что каждый айтишник, будь он разработчиком, сисадмином, сетевым инженером, или даже senior yaml developer`ом, пользуется command line interface. Далеко не все задумываются об улучшении рабочего окружения в CLI и повышении продуктивности работы в терминале. Мне хотелось бы поделиться своим опытом настройки окружения для работы с Linux из Windows.

Настройка окружения в CLI. WSL - Windows Terminal - 1

Из статьи вы узнаете, какими средствами и каким терминалом актуально пользоваться в настоящее время для запуска Linux приложений в Windows 10. Речь пойдёт о WSL 2 и Windows Terminal, набирающим всё большую популярность у пользователей, которым для работы нужен Linux. Так как большинство use-case`ов у меня связаны с удалённым подключением через SSH, большая часть информации будет релевантно для случаев удалённых подключений, со всеми особенностями, связанными с этим (пробросом ssh ключей через ssh agent, пробросом X-сервера, управлением подключениями etс).

Внимание! Под катом много картинок и ужатого, но местами объёмного, gif`а, рекомендуется открывать статью при наличии соответствующего доступа к интернету. Заходите под кат, если вам актуален запуск Linux утилит под Windows, оптимизация работы в окружении CLI, или вы просто любите технические тексты и цветные терминалы. Текст я постарался скрасить скринкастами и скриншотами терминала, чтобы было не скучно.

Введение

Как на домашнем, так и на рабочем ноутбуке, единственная ОС сейчас у меня Windows 10, и в этом году я окончательно перешёл на использование только WSL вместо VM / dualboot / Cygwin / MinGW. Теперь мой терминал по умолчанию — это локальный шелл WSL, где я могу запускать практически любые задачи, как в нативном Linux. Кроме этого, в домашней сети работает мини-сервер Intel NUC, на котором развёрнут Proxmox с LXC контейнерами и KVM, в котором крутится Docker. На все VM хожу по SSH, с ключами из директории Windows. Очень много времени в профессиональной деятельности проходит в CLI, с домашним сервером и сетью тоже самое. Поэтому всегда возникает желание разобраться с инструментами для более комфортной работы в терминале, а в Windows всегда с этим были проблемы. Но сейчас всё меняется.

Настройка окружения в CLI. WSL - Windows Terminal - 2

Эта и последующие статьи больше ориентированы на энтузиастов, которые ищут свежие решения и желают прокачать свой шелл. Но и новичкам должно быть что-то интересно, хотя статья получилась с достаточно глубоким погружением в тему и предполагает, что у читателя есть какие-то фундаментальные знания в Linux. Вся информация собрана на основе личного опыта использования WSL, терминала, а так же бесконечного листания Stack Overflow и Github issues в процессе постоянного усовершенствования конфигов и поиска удобных тулов для работы.

Windows Subsystem for Linux (WSL) 2

В интернете и на Хабре есть несколько нормальных статей про WSL (раз [1] статья про установку/настройку WSL с X-сервером, два [2]заметка про WSL 2, три [3]статья про Python разработку в VSCode с WSL), описывающих установку и настройку системы. Однако не все действия по установке уже актуальны, так же как и ограничений с подводными камнями становится меньше. Я не буду подробно останавливаться на установке, инструкция по установке актуальной (второй) версии WSL есть на сайте Microsoft [4], также в интернете можно найти краткие туториалы [5].

Настройка окружения в CLI. WSL - Windows Terminal - 3

Сейчас WSL ещё находится в стадии активной разработки и недавно (июнь 2019 [6]) вышла новая версия WSL 2, которая на данный момент доступна только для свежих версий Windows участникам Windows Insiders. При возможности советую сразу проапгрейдить WSL до версии 2, так как в ней улучшили работу системных вызовов, работу с сетью, ФС, и в целом она построена на другой архитектуре и по некоторым данным даёт 20-кратный прирост скорости [7] по сравнению с первой версией.

Посмотреть версию Windows 10 и OS build можно в Start -> Settings ->System -> About, для установки WSL 2 требуется версия Windows 1903 и, как минимум, версия билда 18917. Если вы не участник Windows Insider Program [8], вероятнее всего, обновления не прилетят до выхода стабильного релиза. Так что если хочется обновиться до последней сборки, можно включить ранний доступ (Fast) в Start -> Settings -> Update & Security -> Windows Insider Program, обновиться и отключить дальнейшие обновления. Стоит учитывать, что устанавливаться будут ещё не оттестированные массово обновления, что может сказаться на стабильности. 

Стоит иметь ввиду, что до билда версии 18995 [9] WSL имеет баг [10] при работе с файлами на примонтированных дисках Windows, выражающийся в Input/output error, помогает только перезагрузка WSL (wsl --shutdown в PowerShell). В целом сейчас пофиксено много багов, которые до сих пор присутствуют в WSL версии 1 (который ставится по дефолту) и не-preview дистрибутивах Windows. Если у вас обновления ОС регулируются корпоративными политиками, скорее всего самые свежие обновления прилетать не будут и нужно иметь это ввиду. На одном из ноутбуков у меня стоит билд 18956 и обновлений нет, не смотря на то, что выбрана опция Fast в настройках Insider Program. На другом ноутбуке была установлена чистая система несколько месяцев назад и обновления периодически прилетают и устанавливаются.

Установка WSL 2

Для работы WSL требуется включить Hyper-V, потому что дистрибутивы Linux запускаются в легковесных VM с помощью виртуализации Hyper-V.

Настройка окружения в CLI. WSL - Windows Terminal - 4

Далее я приведу краткую инструкция установки из CLI PowerShell дистрибутива WSL на примере Kali Linux [11]). При предпочтении Ubuntu [12]или другого дистрибутива [13] Linux из доступных, заменить ссылку и названия на соответствующие.

Проверить версию билда Windows:

Get-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion" | Select CurrentBuild

Активировать компоненты VirtualMachinePlatform и Microsoft-Windows-Subsystem-Linux:

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

Перезагрузка.
Дальше либо установить дистрибутив из Microsoft Store (https://aka.ms/wslstore [14]), либо дальше выполнить в PowerShell:

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

Запустить консоль WSL (дистрибутив должен был появиться в меню Start, поиск по названию дистра), дождаться приглашения установить нового пользователя, закрыть консоль.

Теперь дистрибутив должен появится в списке, если выполнить в PowerShell:

wsl -l -v

При необходимости преобразовать дистрибутив в формат WSL версии 2:

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

Сделать root пользователем по умолчанию (опционально):

kali config --default-user root

Если вы получили ошибку «A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.», значит у вас стоит билд, в котором проявляется очередной (уже исправленный в последних релизах) баг. Как обычно, есть воркэраунд [15], либо использовать дистрибутив Ubuntu, с ним у меня не было проблем на той же не последней версии билда.

При необходимости, переместить виртуальный диск WSL на другой раздел (отличный от C:) можно по инструкции [16]. Делать это лучше сразу, так как не всё может пройти гладко.

Disclaimer про безопасность. В WSL и на других Linux-серверах в домашней сети я не запускаю никаких критически важных систем, и других пользователей (кроме меня), в сети нет, поэтому я почти везде хожу под root, с ssh аутентификацией через ключи. Я знаю, что это не лучшая практика, однако речь про личное dev-окружение и я не вижу смысла создавать не-root пользователя. Вопросы безопасности в этой статье рассматриваться не будут, об этом я собираюсь когда-нибудь написать отдельно (про то, как в домашней сети без боли организовать взаимодействие сервисов через TLS с централизованным обновлением сертификатов; о синхронизации ~/.ssh/config между серверами, пробросе портов и ключей и т.д.).

Конфигурация WSL

Начиная с билда 17093, основной файл конфигурации WSL находится на ФС дистрибутива по адресу /etc/wsl.conf [17], в нём описываются настройки, которые будут применять при каждой загрузке дистрибутива:

  • Automount — автомонтирование дисков Windows
  • Network — генерировать файлы resolv.conf, hosts
  • Interop — запуск процессов Windows и добавление Windows $PATH в Linux $PATH

Изначально WSL идёт без этого конфига, его нужно прописать вручную:

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

[network]
generateHosts = true
generateResolvConf = true

[interop]
enabled = true
appendWindowsPath = true

Некоторые настойки применяются со значением по умолчанию и с пустым /etc/wsl.conf , но для корректной работы с файлами нужно прописать как минимум параметр options, иначе файлы Windows будут с правами 777 и это нельзя будет изменить из Linux.

Настройка окружения в CLI. WSL - Windows Terminal - 5

Сделать ребут дистрибутива можно из PowerShell командой:

wsl -t kali-linux

После этого можно обновить пакеты и заняться настройкой ОС под себя. Я пока не буду касаться настроек шелла и окружения в Linux, оставлю это для следующей статьи.

apt -y update && apt -y upgrade

Файловая система WSL 2 и производительность

Файлы внутри WSL версии 2 хранятся на виртуальном диске VHDX, в качестве файловой системы используется ext4. Получить доступ к rootfs WSL можно через путь такого формата:

\wsl${DistroName}

Либо, можно набрать «explorer.exe .» в CLI и откроется обозреватель Windows в текущей директории.

В WSL версии 1 не использовался VHDX и был простой доступ к директории, в которой находились файлы Linux, и Microsoft строго не рекомендовали [18] изменять Linux файлы из Windows. В новой версии WSL доступ к ФС на виртуальном диске обеспечивается с помощью файлового сервера Plan 9 Filesystem Protocol [19].

Настройка окружения в CLI. WSL - Windows Terminal - 6

В предыдущих версиях WSL были проблемы с производительностью файловой системой, потому что системные вызовы эмулировались через API Windows, доступ к файлам был медленный и нестабильный. В концу 2019 года в WSL 2 архитектура поменялась и используется нативное ядро Linux. Судя по слайду [20]из youtube-презентации The new Windows subsystem for Linux architecture: a deep dive [21], производительность дисковых операций выросла в 2-5 раз.

Максимальный объём диска ограничен 256GB, при превышении этого объёма необходимо будет делать ресайз, инструкция есть в документации [22].

Изначально, у WSL были проблемы с тем, чтобы высвобождать ресурсы после использования RAM. В билде 19013 эту проблему решили [23]. Если запускать ресурсоёмкие задачи (например, сборка rust приложения) можно заметить, что процесс Vmmem [24]будет в топе Диспетчера задач, однако потребление памяти значительно снизилось в последних версиях WSL.

Настройка окружения в CLI. WSL - Windows Terminal - 7

Сеть 

Имя хоста (hostname) в Linux берётся из имени PC в Windows, независимо от того, что прописать в /etc/hostname или командой hostnamectl set-hostname.

В отличии от первой версии, в WSL 2 сеть работает через через виртуальный 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

Настройка окружения в CLI. WSL - Windows Terminal - 8

В данном случае сеть 172.27.144.0/20 используется под WSL, её первый адрес (172.27.144.1) — это хостовая система Windows.

Из Linux обращаться по сети к хостовым сервисам (запущенным в Windows) можно, например, так:

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

IP-адрес Windows тут берётся из /etc/resolv.conf, где он генерируется автоматически согласно настройкам wsl.conf.

Наоборот, если нужен коннект к Linux сокету из приложения Windows, необходимо обращаться к IP-адресу WSL. При этом есть нюанс — в Linux сервис необходимо запускать не на localhost (127.0.0.1), а на адресе 0.0.0.0. Например, чтобы быстро поднять SOCKS5 proxy до своего VPS [25], нужно запустить SSH с параметром dynamic port forwarding:

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

После этого в приложении Windows, например Chrome, в качестве адреса SOCKS5 прописать не localhost, а адрес WSL, в данном случае 172.27.150.196. Кстати, таким нехитрым способом туннелирования трафика через VPS [25] в Хроме появляется возможность использовать доступ к сайтам через IPv6. 

Настройка окружения в CLI. WSL - Windows Terminal - 9

IP-адрес в Linux после перезагрузки будет каждый раз меняться, так что в сценариях, когда нужно иметь постоянно работающий и автоматически запускающийся port forwarding, нужно искать воркэраунд. Есть много способов решения этой проблемы, разной степени костыльности, почитать подробнее можно в этом issue [26]на github. Я воспользовался утилитой go-wsl2-host [27], которая реализует Windows Service, добавляющий автоматически IP-адрес WSL в файл hosts Windows, таким образом на хостовой системе можно прописать хостнейм типа ubuntu.wsl и по нему обращаться к Linux. Однако всё это костыли и работает не очень хорошо, остаётся ждать, когда Microsoft пофиксят эти проблемы.

Настройка окружения в CLI. WSL - Windows Terminal - 10

UPD. Пока я писал эту статью, обнаружил, что вышли обновления (билд 18945 [28]), в которых появилась возможность достучаться через localhost до сервисов, запущенных в WSL. Правда, оказалось, что есть баг [29], из-за которого всё равно это не работало у всех, фикс [30]в августовском билде 18970. Так как не всем прилетают обновления, даже если быть участником программы Windows Insiders, я не стал корректировать информацию, может кому-то это поможет настроить сетевое взаимодействие.

OpenSSH в Windows и автозапуск сервисов

Windows 10, как и Windows Server 2019, комплектуется форком OpenSSH [31], включающем все знакомые утилиты ssh-keygen, ssh-add, scp и другие, а том числе ssh-agent и сам сервер sshd. И клиент, и сервер поставить можно через Apps > Apps and Features > Manage Optional Features, но версия клиента ssh будет не последняя. Я столкнулся с багом, не позволяющим коннектиться к хосту через jump-хост с опцией ProxyJump и оказалось, что эту проблему пофиксили, но нужно вручную обновить SSH клиента. Установить актуальную версию Win32 OpenSSH можно, скачав zip из раздела Releases [32] на гитхабе, и распаковав, к примеру, в C:Program FilesOpenSSH. Сторонним софтом ssh.exe (например, при использовании Remote Development режима в VSCode) вызывается из $PATH (%SYSTEMROOT%System32OpenSSH), нужно изменить переменную среды. Environment variables изменяются через GUI в Start > Edit the system environment variables (Пуск > Изменение системных переменных среды), там необходимо новый путь поставить выше старой версии. 

Так как в WSL не работает Systemd, есть проблема с автозапуском сервисов со стартом системы. Есть несколько способов настроить автостарт ssh сервера в WSL, самый простой — это создать задачу в Task Scheduler, где прописать команду старта сервера. В интернете можно найти разные инструкции [33]автозапуска через скрипты vbs, ps1 или bat. Проблема почти всех способов в том, что триггером является запуск основной ОС Windows, то есть, если произойдёт сбой WSL и придётся перезапускать систему (wsl -t), то Linux запустится без запущенного сервиса. При старте Windows дистрибутив WSL запускается только в момент первого обращения к нему.

Я использую SSH-сервер на ноутбуке внутри WSL для того, чтобы удалённо можно было ходить с машины на машину. И, благодаря тому, что я использую техники ssh port forwarding и продуманно настроенный централизованный конфиг SSH клиентов, я могу прозрачно ходить по всем своим серверам, вводя хостнейм вместо адресов. То есть, если даже подключить какой-то из ноутбуков к мобильной сети, autossh демон подключится к jump-хосту и я всё равно смогу зайти на компьютер, никакой NAT не будет помехой. Поэтому мне важно, чтобы sshd всё время был в состоянии up.

Настройка окружения в CLI. WSL - Windows Terminal - 11

Единственный рабочий способ попасть по SSH в WSL — это пробросить порт SSH. Это можно сделать с самого WSL с помощью RemoteForward, либо с другого сервера в домашней сети. Мало лишь кому это надо, да и это уже advanced level, так что просто приведу рабочую команду:

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

Теперь при коннекте на адрес mt.example.com:2263 можно попасть прямо в WSL.

Если планируется поднимать SSH-сервер в WSL, нужно не забыть сконфигурировать необходимые параметры запуска сервера в /etc/ssh/sshd_config. Чтобы не было конфликта при бинде сервиса на порт 22, OpenSSH сервер в Windows следует отключить или вовсе удалить, если он установлен (Apps > Apps and Features > Manage Optional Features). 

X forwarding

Приятным моментом оказалось, что в Windows 10 есть утилита clip.exe, позволяющая перенаправлять stdout напрямую в буфер обмена Windows. Это удобно использовать в таких программах как tmux, а благодаря пробросу X-сервера текст можно копировать и с удалённых хостов. Чтобы всё работало, необходимо иметь всегда запущенный X-сервер в Windows и правильно прописанную переменную $DISPLAY

Немного скучной теории. На *nix системах с запущенным X имеются разные типы буферов обмена (primary, secondary, clipboard), в контексте этой статьи это не так важно, но важно для общего понимания механизма работы. Для работы с буферами обмена на Linux есть две утилиты (xclip и xsel). Обе утилиты имеют схожий функционал, в xsel его немного больше, но базовый функционал, необходимый для проброса содержимого буфера, одинаков. В X приложениях выделенный текст попадает в primary selection, вставляется при этом средней кнопкой мышки, в xclip и xsel используется по умолчанию primary selection.

Например, чтобы скопировать в буфер по умолчанию содержимое переменной, нужно передать stdout на stdin утилиты xclip, без дополнительных параметров:

❯❯ echo -n $DISPLAY | xclip

А чтобы вывести содержимое буфера по умолчанию, запустить xclip с ключом -o:

❯❯ xclip -o
172.20.160.1:0

Чтобы буфер обмена перенаправлялся через X-сервер и графические приложения запускались на локальном сервере X, необходимо в переменную $DISPLAY прописать IP-адрес, являющийся default gateway для WSL. Пока что ничего лучше того, чтобы брать его из resolv.conf (который генерируется автоматически Windows), не придумали. Поэтому, самый простой способ — прописать экспорт переменной $DISPLAY в профайле шелла (например, ~/.zshrc для zsh).

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

Настройка окружения в CLI. WSL - Windows Terminal - 12

В качестве X-сервера я выбрал бесплатный VcXsrv [34], он умеет работать с буфером, имеет разные режимы отображения окон и запускается из командной строки с прописанными опциями. По ссылке на gist [35] можно посмотреть все опции.

Создать задачу автозапуска X-сервера можно в Task Scheduler примерно таким образом:

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

SSH ключи

Чтобы программы из Windows могли использовать SSH ключи (например, редактор при работе с удалённым репозиторием GitHub), и в то же время не было второй копии ключей в WSL, лучше всего сгенерировать ключи в Windows %HOMEPATH%/.ssh и создать симлинки в домашней директории 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

Либо, в ~/.ssh/config можно прописать параметр IdentityFile, указав путь к ключам на диске Windows:

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

Если ключи были скопированы откуда-то и права на файлы не выставлены правильно, поправить permissions:

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

Настройка окружения в CLI. WSL - Windows Terminal - 13

Таким образом, при дальнейшей настройке доступа по ключам SSH [36] пользователь идентифицируется однозначно одним набором ключей в одном месте, как при использовании приложений Windows, так и Linux. Теперь можно добавить публичный ключ на сервера/сервисы, куда необходимо будет ходить с этого компьютера. Если в домашней сети есть другие устройства, на которые требуется доступ по SSH, то правильно будет скопировать свой публичный ключ на эти сервера (ssh-copy-id), но не надо копировать ключи одного сервера на другой. Так как при работе через SSH можно (и нужно) использовать ssh-agent, то при коннекте с одного сервера на другой, агент заботится, чтобы авторизация происходила по проброшенному ключу. Чтобы всё работало правильно и ожидаемо, нужно позаботиться о файле ~/.ssh/config, [37]в котором надо прописать все необходимые опции.

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

Какой терминал выбрать для работы в Linux на Windows

Сначала хочется сделать небольшое ревью существующих терминальных оболочек под Windows, умеющих запускать WSL. Среди пользователей популярен функциональный комбайн MobaXterm [38], который умеет создавать различные сессии, в том числе графические (WSL, bash/zsh, Mosh, RDP, VNC и т.п.), позволяет делать макросы и запускать скрипты, имеет много настроек и функциональных возможностей, ssh agent, автозапускаемый ssh port forwarding, и даже имеет встроенный сервер ftp/tftp/http, но продукт closed source и, к тому же, платный. Hyper [39] — другой, более современный эмулятор терминала, позволяющий запускать WSL shell, терминал построен на HTML/JS/CSS и расширяется с помощью плагинов в виде node.js модулей (awesome list [40]). Есть и другие терминалы, позволяющие запускать WSL с разной степенью костыльности (ConEmu [41], его форк Cmder [42], WSLtty [43] и др.), но их я оставлю без внимания.

Настройка окружения в CLI. WSL - Windows Terminal - 14

Дальше в этой статье речь пойдёт про Windows Terminal, на который я перешёл с недавних пор, и пока что испытываю только положительные эмоции. Terminal [44] пока что ещё в статусе бета, но работает достаточно стабильно. Из фич на данный момент реализован мультитаб, разделение панелей (splitting), настраиваемые профили терминальных подключений, цветовые схемы, ну и больше нечего перечислить. Но этого функционала вполне хватает, мне даже нравится, что софт не перегружен лишним — как будто бы разработчики придерживаются принципа KISS [45].

Terminal эволюционировал из проекта Windows Console (ConPTY), научившись поддерживать ANSI/VT последовательности, 24-bit RGB true color и UTF-8. По ссылкам (начало [46], продолжение [47]) на Хабре замечательный перевод серии постов блога Windows Command-Line: Inside the Windows Console [48], где рассказывается про историю создания терминалов, связанные с этим стандарты передачи управляющих последовательностей, кодовые страницы, юникод, появление эмуляторов терминалов и в дальнейшем уже эволюцию командной строки Windows. Техногикам это может быть интересно. Инженерный состав, работающий над этим opensource проектом, ведёт девблог Windows Command Line [49], который более, чем полностью посвящён WSL и Windows Terminal. Никогда бы до этого момента не поверил бы, что буду с интересом наблюдать за развитием продуктов MS, но что они делают в рамках развития WSL, Terminal и VSCode, действительно заслуживает уважения. Как начиналось развитие WSL, описано в Microsoft Open Source Stories [50] (перевод [51] есть на Хабре). Кстати, Microsoft с 2016 года является платиновым участником Linux Foundation [52].

Установка и настройка Windows Terminal

Установить Windows Terminal можно из Windows Store [53], либо скачав бинарник из раздела Releases [44] на гитхабе проекта, там же и вся актуальная информация, инструкции и FAQ. Терминал требует, как минимум, версию Windows 1903 и билд 18362. Предпочтительнее устанавливать через Windows Store, так как обновлять в этом случае проще, прямо из стора. Обновления выходят регулярно, на гитхабе выложен план развития (roadmap [54]) первой версии терминала. На данный момент все фичи версии 1 уже реализованы (по плану до конца 2019 года реализовать все улучшения), дальше несколько месяцев работы над устранениями багов и в апреле 2020 планируется официальный релиз Terminal v1.0. Приятно, что MS теперь есть на гитхабе, их софт научился показывать логи, внятные ошибки и любые проблемы легко гуглятся.

Настройка окружения в CLI. WSL - Windows Terminal - 15

Настроек в терминале пока не много, но их хватает для комфортной работы, продукт активно развивается, есть на github [44], где пользователи могут создать feature request или bug report. Разработчики принимают участие в обсуждении проблем с пользователями, зачастую предлагая воркэраунды, когда обнаруживается баг.

Настройка окружения в CLI. WSL - Windows Terminal - 16

Конфиг хранится в json формате, после сохранения применяется сразу же. Это удобно хотя бы потому, что можно применять хорошие практики управлением конфигурациями рабочего окружения — все линуксовые конфиги я храню в git репозитории, на Windows из рабочего инструмента использую только VSCode, который умеет синхронизировать конфиг через github gist, а локальный конфиг воркспейса сохранять отдельно в dotfiles. Вот и Terminal движется в ту же сторону, используя те же хоткеи и формат конфига, как VSCode. Править конфиг, кстати, удобно через VSCode, особенно если уже пользуетесь этим отличным редактором от MS. Файл конфигурации терминала уже содержит многие дефолтные настройки, а правильный редактор позволяет посмотреть все опции с описанием key и вариантами value из schema [55] (особенно это удобно, когда у проекта ещё нет полноценной документации). Плюсом доступны все фишечки IDE в виде автодополнения, intellisense, проверкой синтаксиса, форматированием и т.д. 

Настройка окружения в CLI. WSL - Windows Terminal - 17

Документация для разработчиков доступна тут [56], а здесь [57]пока что небольшая страничка документации для пользователей. Отдельная страница [58]посвящена настройкам, которые прописываются в json файле конфигурации. Оттуда можно узнать, что структурно настройки делятся на:

  • Global (профиль по умолчанию, изначальный размер окна терминала, тема и т.д.)
  • Key Bindings (настройки сочетаний клавиш)
  • Profiles (настройки, специфичные для каждого терминала)
  • Schemes (цветовые схемы)

Есть такое понятие, как динамические профили, они появляются в конфиге автоматически и имеют свойство source. Это касается дистрибутивов WSL и Azure Cloud Shell. Чтобы создать дубликат профиля одного и того же дистрибутива WSL (например, Ubuntu), необходимо сгенерировать GUID [59] и прописать все желаемые настройки, кроме source, а в качестве commandline прописать wsl -d {DistroName}.

Шрифты

Чтобы терминал по-настоящему радовал пользователя, обязательно надо инсталлировать шрифты с поддержкой спец символов и лигатур. Выбрать можно из:

Я использую программерский шрифт Fira Code как в терминале, так и в редакторе. Им поддерживаются большинство символов, используемых в в оформлении CLI программ и консольных интерфейсов, лигатуры, а также нет никаких проблем с отображением эмодзи в терминале.

Настройка окружения в CLI. WSL - Windows Terminal - 18

Устанавливается шрифт в Windows с помощью установщика шрифтов ОС. Для этого надо скачать последнюю версию понравившегося шрифта с github releases архивом и вручную установить шрифт в системе.

Посмотреть название шрифта (настройка терминала fontFace) можно при установке или после в приложении Character Map (Таблица Символов). Кроме этого, в Start -> Settings -> Personalization -> Fonts можно посмотреть, как шрифт рендерится в разных режимах, и заодно проверить, как рисуются лигатуры.

Настройка окружения в CLI. WSL - Windows Terminal - 19

Заключение

Получилась очень объёмная статья, в одном месте собрана вся актуальная информация по установке, настройке и использованию Windows Terminal совместно с WSL. В дальнейшем я хочу так же оформить статьёй заметки о ZSH и tmux, и расписать свой опыт деплоя конфигураций на VM и синхронизации dotfiles между хостами. Всё в рамках автоматизации домашней сети, но это будет полезно и для разработчиков / девопсов / системных инженеров. Ещё из нераскрытых тем остался запуск Docker в WSL 2 [64], но у меня нет необходимости запускать докер на персональном компьютере, так как для этого есть выделенный сервер [25].

Я надеюсь, что никто не пожалел, что дочитал статью и вынес для себя какие-то новые знания. Если кому-то есть, что добавить, давайте делиться мыслями в комментариях. Если есть какие-то замечания по тексту, пишите в ЛС, хочется поддерживать этот гайд в актуальности.

References

Автор: Mikhail Kulikov

Источник [66]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/ssh/341163

Ссылки в тексте:

[1] раз: https://habr.com/ru/post/412633/

[2] два : https://habr.com/ru/post/451782/

[3] три : https://habr.com/ru/post/472202/

[4] есть на сайте Microsoft: https://docs.microsoft.com/ru-ru/windows/wsl/wsl2-install

[5] туториалы: https://github.com/QMonkey/wsl-tutorial/blob/master/README.wsl2.md

[6] июнь 2019: https://habr.com/ru/company/microsoft/blog/456204/

[7] 20-кратный прирост скорости: https://devblogs.microsoft.com/commandline/announcing-wsl-2/

[8] Windows Insider Program: https://insider.windows.com/ru-ru/how-to-pc/

[9] 18995: https://blogs.windows.com/windowsexperience/2019/10/03/announcing-windows-10-insider-preview-build-18995/#vF3ozdYIr7IckCmL.97

[10] баг: https://github.com/microsoft/WSL/issues/4377

[11] Kali Linux: https://www.kali.org/news/wsl2-and-kali/

[12] Ubuntu : https://aka.ms/wsl-ubuntu-1804

[13] другого дистрибутива: https://docs.microsoft.com/ru-ru/windows/wsl/install-manual#downloading-distros

[14] https://aka.ms/wslstore: https://aka.ms/wslstore

[15] воркэраунд: https://expertonsomething.com/2019/08/25/fixing-kali-linux-on-windows-wsl2/

[16] инструкции: https://github.com/MicrosoftDocs/WSL/issues/412

[17] /etc/wsl.conf: https://devblogs.microsoft.com/commandline/automatically-configuring-wsl/

[18] строго не рекомендовали: https://devblogs.microsoft.com/commandline/do-not-change-linux-files-using-windows-apps-and-tools/

[19] Plan 9 Filesystem Protocol: https://en.wikipedia.org/wiki/9P_(protocol)

[20] слайду : https://habrastorage.org/webt/mq/eu/u4/mqeuu4ndvp17tr3vmdygp6janyo.png

[21] The new Windows subsystem for Linux architecture: a deep dive: https://www.youtube.com/watch?v=lwhMThePdIo

[22] документации: https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes#understanding-wsl-2-uses-a-vhd-and-what-to-do-if-you-reach-its-max-size

[23] решили: https://devblogs.microsoft.com/commandline/memory-reclaim-in-the-windows-subsystem-for-linux-2/

[24] Vmmem : https://devblogs.microsoft.com/oldnewthing/20180717-00/?p=99265

[25] VPS: https://www.reg.ru/?rlink=reflink-717

[26] issue : https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723

[27] go-wsl2-host: https://github.com/shayne/go-wsl2-host

[28] 18945: https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-insiders-preview-build-18945/

[29] баг: https://github.com/microsoft/WSL/issues/4353#issuecomment-516963093

[30] фикс : https://github.com/MicrosoftDocs/WSL/releases/tag/18970

[31] форком OpenSSH: https://github.com/PowerShell/openssh-portable

[32] Releases: https://github.com/PowerShell/Win32-OpenSSH/releases/

[33] инструкции: https://superuser.com/questions/1112007/how-to-run-ubuntu-service-on-windows-at-startup?noredirect=1&lq=1

[34] VcXsrv: https://sourceforge.net/projects/vcxsrv/

[35] ссылке на gist: https://gist.github.com/stowler/9921780

[36] доступа по ключам SSH: https://habr.com/ru/post/122445/

[37] ~/.ssh/config, : https://www.ssh.com/ssh/config/

[38] MobaXterm: https://mobaxterm.mobatek.net/

[39] Hyper : https://github.com/zeit/hyper

[40] awesome list: https://github.com/bnb/awesome-hyper

[41] ConEmu: https://conemu.github.io/en/BashOnWindows.html

[42] Cmder: https://jackwarren.info/blog/cmder

[43] WSLtty: https://github.com/mintty/wsltty

[44] Terminal: https://github.com/microsoft/terminal

[45] KISS: https://en.wikipedia.org/wiki/KISS_principle

[46] начало: https://habr.com/ru/post/417679/

[47] продолжение: https://habr.com/ru/post/420853/

[48] Windows Command-Line: Inside the Windows Console: https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/

[49] Windows Command Line: https://devblogs.microsoft.com/commandline/

[50] Microsoft Open Source Stories: https://medium.com/microsoft-open-source-stories/when-linux-came-to-windows-204cf9abb3d6

[51] перевод: https://habr.com/ru/company/ruvds/blog/461663/

[52] Linux Foundation : https://en.wikipedia.org/wiki/Linux_Foundation#Members

[53] Windows Store: https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701

[54] roadmap: https://github.com/microsoft/terminal/blob/master/doc/terminal-v1-roadmap.md

[55] schema: https://github.com/microsoft/terminal/blob/master/doc/cascadia/SettingsSchema.md

[56] тут: https://github.com/microsoft/terminal/tree/master/doc

[57] здесь : https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md

[58] страница : https://github.com/microsoft/terminal/blob/master/doc/user-docs/UsingJsonSettings.md

[59] сгенерировать GUID: http://new-guid.com/

[60] Fira Code: https://github.com/tonsky/FiraCode

[61] Hack: https://github.com/source-foundry/Hack

[62] любые : https://github.com/powerline/fonts

[63] другие : https://github.com/ryanoasis/nerd-fonts

[64] Docker в WSL 2: https://docs.docker.com/docker-for-windows/wsl-tech-preview/

[65] WSL 2 is now available in Windows Insiders: https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/

[66] Источник: https://habr.com/ru/post/481746/?utm_source=habrahabr&utm_medium=rss&utm_campaign=481746