- PVSM.RU - https://www.pvsm.ru -
Есть люди, которые большинство рабочего времени проводят в консоли, есть те, кто пользуются терминалом при необходимости, запуская что-то по инструкциям. Но я думаю, что каждый айтишник, будь он разработчиком, сисадмином, сетевым инженером, или даже senior yaml developer`ом, пользуется command line interface. Далеко не все задумываются об улучшении рабочего окружения в CLI и повышении продуктивности работы в терминале. Мне хотелось бы поделиться своим опытом настройки окружения для работы с Linux из Windows.
Из статьи вы узнаете, какими средствами и каким терминалом актуально пользоваться в настоящее время для запуска 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 всегда с этим были проблемы. Но сейчас всё меняется.
Эта и последующие статьи больше ориентированы на энтузиастов, которые ищут свежие решения и желают прокачать свой шелл. Но и новичкам должно быть что-то интересно, хотя статья получилась с достаточно глубоким погружением в тему и предполагает, что у читателя есть какие-то фундаментальные знания в Linux. Вся информация собрана на основе личного опыта использования WSL, терминала, а так же бесконечного листания Stack Overflow и Github issues в процессе постоянного усовершенствования конфигов и поиска удобных тулов для работы.
В интернете и на Хабре есть несколько нормальных статей про WSL (раз [1] статья про установку/настройку WSL с X-сервером, два [2]заметка про WSL 2, три [3]статья про Python разработку в VSCode с WSL), описывающих установку и настройку системы. Однако не все действия по установке уже актуальны, так же как и ограничений с подводными камнями становится меньше. Я не буду подробно останавливаться на установке, инструкция по установке актуальной (второй) версии WSL есть на сайте Microsoft [4], также в интернете можно найти краткие туториалы [5].
Сейчас 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 требуется включить Hyper-V, потому что дистрибутивы Linux запускаются в легковесных VM с помощью виртуализации Hyper-V.
Далее я приведу краткую инструкция установки из 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 между серверами, пробросе портов и ключей и т.д.).
Начиная с билда 17093, основной файл конфигурации WSL находится на ФС дистрибутива по адресу /etc/wsl.conf [17], в нём описываются настройки, которые будут применять при каждой загрузке дистрибутива:
Изначально 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.
Сделать ребут дистрибутива можно из PowerShell командой:
wsl -t kali-linux
После этого можно обновить пакеты и заняться настройкой ОС под себя. Я пока не буду касаться настроек шелла и окружения в Linux, оставлю это для следующей статьи.
apt -y update && apt -y upgrade
Файлы внутри 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].
В предыдущих версиях 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.
Имя хоста (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
В данном случае сеть 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 до своего
❯❯ ssh -D 0.0.0.0:2299 -N -f proxy.example.com
После этого в приложении Windows, например Chrome, в качестве адреса SOCKS5 прописать не localhost, а адрес WSL, в данном случае 172.27.150.196. Кстати, таким нехитрым способом туннелирования трафика через
IP-адрес в Linux после перезагрузки будет каждый раз меняться, так что в сценариях, когда нужно иметь постоянно работающий и автоматически запускающийся port forwarding, нужно искать воркэраунд. Есть много способов решения этой проблемы, разной степени костыльности, почитать подробнее можно в этом issue [26]на github. Я воспользовался утилитой go-wsl2-host [27], которая реализует Windows Service, добавляющий автоматически IP-адрес WSL в файл hosts Windows, таким образом на хостовой системе можно прописать хостнейм типа ubuntu.wsl и по нему обращаться к Linux. Однако всё это костыли и работает не очень хорошо, остаётся ждать, когда Microsoft пофиксят эти проблемы.
UPD. Пока я писал эту статью, обнаружил, что вышли обновления (билд 18945 [28]), в которых появилась возможность достучаться через localhost до сервисов, запущенных в WSL. Правда, оказалось, что есть баг [29], из-за которого всё равно это не работало у всех, фикс [30]в августовском билде 18970. Так как не всем прилетают обновления, даже если быть участником программы Windows Insiders, я не стал корректировать информацию, может кому-то это поможет настроить сетевое взаимодействие.
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.
Единственный рабочий способ попасть по 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).
Приятным моментом оказалось, что в 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
В качестве 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
Чтобы программы из 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
Таким образом, при дальнейшей настройке доступа по ключам 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
Сначала хочется сделать небольшое ревью существующих терминальных оболочек под 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] и др.), но их я оставлю без внимания.
Дальше в этой статье речь пойдёт про 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 Store [53], либо скачав бинарник из раздела Releases [44] на гитхабе проекта, там же и вся актуальная информация, инструкции и FAQ. Терминал требует, как минимум, версию Windows 1903 и билд 18362. Предпочтительнее устанавливать через Windows Store, так как обновлять в этом случае проще, прямо из стора. Обновления выходят регулярно, на гитхабе выложен план развития (roadmap [54]) первой версии терминала. На данный момент все фичи версии 1 уже реализованы (по плану до конца 2019 года реализовать все улучшения), дальше несколько месяцев работы над устранениями багов и в апреле 2020 планируется официальный релиз Terminal v1.0. Приятно, что MS теперь есть на гитхабе, их софт научился показывать логи, внятные ошибки и любые проблемы легко гуглятся.
Настроек в терминале пока не много, но их хватает для комфортной работы, продукт активно развивается, есть на github [44], где пользователи могут создать feature request или bug report. Разработчики принимают участие в обсуждении проблем с пользователями, зачастую предлагая воркэраунды, когда обнаруживается баг.
Конфиг хранится в json формате, после сохранения применяется сразу же. Это удобно хотя бы потому, что можно применять хорошие практики управлением конфигурациями рабочего окружения — все линуксовые конфиги я храню в git репозитории, на Windows из рабочего инструмента использую только VSCode, который умеет синхронизировать конфиг через github gist, а локальный конфиг воркспейса сохранять отдельно в dotfiles. Вот и Terminal движется в ту же сторону, используя те же хоткеи и формат конфига, как VSCode. Править конфиг, кстати, удобно через VSCode, особенно если уже пользуетесь этим отличным редактором от MS. Файл конфигурации терминала уже содержит многие дефолтные настройки, а правильный редактор позволяет посмотреть все опции с описанием key и вариантами value из schema [55] (особенно это удобно, когда у проекта ещё нет полноценной документации). Плюсом доступны все фишечки IDE в виде автодополнения, intellisense, проверкой синтаксиса, форматированием и т.д.
Документация для разработчиков доступна тут [56], а здесь [57]пока что небольшая страничка документации для пользователей. Отдельная страница [58]посвящена настройкам, которые прописываются в json файле конфигурации. Оттуда можно узнать, что структурно настройки делятся на:
Есть такое понятие, как динамические профили, они появляются в конфиге автоматически и имеют свойство source. Это касается дистрибутивов WSL и Azure Cloud Shell. Чтобы создать дубликат профиля одного и того же дистрибутива WSL (например, Ubuntu), необходимо сгенерировать GUID [59] и прописать все желаемые настройки, кроме source, а в качестве commandline прописать wsl -d {DistroName}.
Чтобы терминал по-настоящему радовал пользователя, обязательно надо инсталлировать шрифты с поддержкой спец символов и лигатур. Выбрать можно из:
Я использую программерский шрифт Fira Code как в терминале, так и в редакторе. Им поддерживаются большинство символов, используемых в в оформлении CLI программ и консольных интерфейсов, лигатуры, а также нет никаких проблем с отображением эмодзи в терминале.
Устанавливается шрифт в Windows с помощью установщика шрифтов ОС. Для этого надо скачать последнюю версию понравившегося шрифта с github releases архивом и вручную установить шрифт в системе.
Посмотреть название шрифта (настройка терминала fontFace) можно при установке или после в приложении Character Map (Таблица Символов). Кроме этого, в Start -> Settings -> Personalization -> Fonts можно посмотреть, как шрифт рендерится в разных режимах, и заодно проверить, как рисуются лигатуры.
Получилась очень объёмная статья, в одном месте собрана вся актуальная информация по установке, настройке и использованию Windows Terminal совместно с WSL. В дальнейшем я хочу так же оформить статьёй заметки о ZSH и tmux, и расписать свой опыт деплоя конфигураций на VM и синхронизации dotfiles между хостами. Всё в рамках автоматизации домашней сети, но это будет полезно и для разработчиков / девопсов / системных инженеров. Ещё из нераскрытых тем остался запуск Docker в WSL 2 [64], но у меня нет необходимости запускать докер на персональном компьютере, так как для этого есть
Я надеюсь, что никто не пожалел, что дочитал статью и вынес для себя какие-то новые знания. Если кому-то есть, что добавить, давайте делиться мыслями в комментариях. Если есть какие-то замечания по тексту, пишите в ЛС, хочется поддерживать этот гайд в актуальности.
Автор: 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
Нажмите здесь для печати.