Windows terminal ubuntu profile — Ваш верный помощник с OS Windows

3 minute read

Windows Terminal is a powerful tool that can unify multiple command-line interfaces, including Ubuntu (via WSL) and PuTTY. This guide will help you integrate both into Windows Terminal for an efficient and streamlined workflow.

Step 1. Install Windows Terminal

If you haven’t already, install Windows Terminal from the Microsoft Store:

Open the Microsoft Store.
Search for Windows Terminal.
Click Install.

Step 2. Add Ubuntu to Windows Terminal

Install WSL
To use Ubuntu, you must enable and install the Windows Subsystem for Linux (WSL):

Open PowerShell as Administrator and run:

This installs the latest version of WSL along with a default Linux distribution, usually Ubuntu.
If Ubuntu is not installed, you can manually install it from the Microsoft Store:
- Open the Microsoft Store.
- Search for Ubuntu.
- Install the version you prefer (e.g., Ubuntu 20.04).
  or,
- Run the following command in PowerShell:
Once installed, launch Ubuntu to set up your username and password.
To set up a user and password, run the following command in Ubuntu:

Check Installed WSL Distributions
Run the following command in PowerShell to verify Ubuntu is installed:

You’ll see a list of all installed WSL distributions.

Step 3: Add Ubuntu Profile to Windows Terminal

Ubuntu is usually added automatically. If not, add it manually:

Open Windows Terminal.
Click the down arrow in the top menu and select Settings.
Scroll down to JSON file or click “Open JSON file” to edit it directly.

Add the following JSON snippet for Ubuntu:

 {
     "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
     "name": "Ubuntu",
     "source": "Windows.Terminal.Wsl",
     "icon": "ms-appx:///ProfileIcons/{2c4de342-38b7-51cf-b940-2309a097f518}.png",
     "hidden": false
 }

Save and close the JSON file.
Or, Click on the dropdown menu and select Settings.
Click on the Add a new profile button.
Click on the New empty profile button.
Add name as Ubuntu and set the commandline as wsl.exe -d Ubuntu.
Restart Windows Terminal, and Ubuntu will appear in the dropdown menu.

Step 4. Add PuTTY to Windows Terminal

PuTTY is a popular SSH client and can also be integrated into Windows Terminal.

Install PuTTY

Download PuTTY from the official PuTTY website.
Install PuTTY on your system.

Add a Profile for PuTTY

Open Windows Terminal.
Go to Settings and open the JSON file for editing.

Add the following JSON snippet to configure PuTTY:

  {
      "commandline": "C:\\Program Files\\PuTTY\\putty.exe",
      "guid": "{82a5e4dc-8b1d-4635-804d-0f03a20aff5e}",
      "hidden": false,
      "icon": "C:\\Program Files\\PuTTY\\putty.ico",
      "name": "PuTTY",
      "startingDirectory": "%USERPROFILE%"
  },

Or, Click on the dropdown menu and select Settings.
Click on the Add a new profile button.
Click on the New empty profile button.
Add name as PuTTY and set the commandline as C:\Program Files\PuTTY\putty.exe.
Save and restart Windows Terminal. PuTTY will now be available in the dropdown menu.

Customize Ubuntu and PuTTY Profiles

Customization Options
You can further customize each profile with options like fonts, color schemes, or starting directories:

{
    "fontFace": "Cascadia Code PL",
    "colorScheme": "Campbell",
    "startingDirectory": "//wsl$/Ubuntu/home/<your-username>",
    "backgroundImage": "C:/path/to/your/background.png",
    "backgroundImageOpacity": 0.5
}

Steps to Apply Customization

Replace <your-username> with your Ubuntu username.
Update paths to match your setup.
Save and restart Windows Terminal.

Verify Profiles

To verify your configuration:
- Open Windows Terminal.
- Click the dropdown menu and check if Ubuntu and PuTTY appear.
- Launch each profile to ensure they work correctly.

Bonus: Enable SSH with Ubuntu

You can also use Ubuntu for SSH connections instead of PuTTY by installing OpenSSH:

Open Ubuntu and run:

 sudo apt update
 sudo apt install openssh-client

Use SSH commands directly in your Ubuntu profile, such as:

Conclusion

By integrating Ubuntu and PuTTY into Windows Terminal, you can manage your development and administrative tasks more efficiently. The unified interface allows for seamless switching between environments, enhancing your productivity and workflow.

Источник

Introduction

Throughout my career I have used Windows, Linux, Mac and Windows again, and each year that passes I discover myself using the terminal more and more. Most of my work is done there, except when doing some heavy coding. Therefore I believe it is important to have the same flow no matter which operative system is in use in order not to lose productivity.

Back when using Windows, the WSL (Windows Subsystem for Linux) did not exist, and therefore the portability between Unix and Windows was unthinkable. Now with WSL, one is able to install brew and manage all of the non-GUI related programs in the same way that on Mac and Linux.

This guide is very opinionated towards what my flow is, however, you can pick and choose what you prefer. There are some sections that are only Windows or Mac related so do the ones that are applicable to your operative system.

[Windows] Enable WSL

As mentioned before, enabling the Linux sub-system is the starting point for Windows.

Open a cmd terminal as administrator and execute: wsl --install.
After logging in, execute: sudo apt update; sudo apt upgrade.

A reboot might be needed after the 1st or 2nd step. When that is done, open the Windows Terminal, you can download it from the microsoft store if you don’t have it, and set up Ubuntu as your default profile from the preferences menu.

From now on, every time you have to execute a command you will do it on the Windows Terminal with the Ubuntu profile, unless the guide says otherwise. The Ubuntu profile will also be later configured in Visual Studio Code as the default terminal.

Fonts

The terminal tooling, that is going to be installed later, requires quite a lot of support for font icons such as folders, home, branches, etc; therefore a complete font is needed. Download and install CaskaydiaCove NF.

Homebrew

Brew is the preferred package manager on Mac and it also works on Ubuntu, meaning it also works on WSL. Install Homebrew by executing the following command either on the Windows Terminal or the default terminal on Mac / Linux.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

After installing it, you will notice a suggestion message to execute two commands, these contain path related information, so be sure to copy paste from your terminal. In my case they looked like this:

echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/pabmo/.profile
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

ZSH, jump and OhMyPosh

OhMyPosh is a modern replacement for oh-my-zsh or oh-my-fish. It is built in Go and the configuration is described in a json file which is very understandable and portable. Create one you like, use it for all your environments, share it with your friends and community!

Jump, installed in the 5th step, allows one to jump from directory to directory; in other words, if you visit the path user/documents/devandchill you can later jump from any other directory to the mentioned one executing j devand and so.

Execute in order:

brew install zsh.
Follow instructions (if any) to make zsh default shell instead of bash.
brew install zsh-completions.
brew install zsh-syntax-highlighting.
Save the path that brew reports after installing the syntax highlighting.
brew install jump.
brew tap jandedobbeleer/oh-my-posh && brew install oh-my-posh.

In your terminal create the file ~/.zshrc if it does not yet exists and add the contents below. Feel free to remove the parts annotated with ## OPTIONAL.

## MAKE HISTORY TO BE PRESERVED FOR SEARCH
HISTFILE=~/.zsh_history
HISTSIZE=10000
SAVEHIST=10000
setopt appendhistory

## UP AND DOWN SEARCH HISTORY BEGINNING WITH BUFFERED WORD
## https://superuser.com/a/418299
bindkey '\e[A' history-beginning-search-backward
bindkey '\e[B' history-beginning-search-forward

## OPTIONAL: ALIASES
alias kb='kubectl'
alias git='LANG=en_GB git'
alias dcd='docker compose down -v --remove-orphans'
alias dcu='docker compose pull; docker compose up -d'
alias me='eval $(minikube -p minikube docker-env)'
alias uuid='uuidgen | tr '\''[:upper:]'\'' '\''[:lower:]'\'' | tee /dev/stderr | pbcopy'
alias gorun='env $(cat local.env) go run cmd/main.go'
alias gotest='env $(cat local.env) go test -v -tags=integration --count=1 ./...'

## EXPORTS
export GPG_TTY=$(tty)

## OPTIONAL: EXPORTS - MAY NEED DIRECTORY MODIFICATIONS
export GOPATH=$HOME/go
export DOTNET_HOME=/usr/local/share/dotnet/dotnet
export PATH=$PATH:$GOPATH/bin:$DOTNET_HOME/bin

## ZSH COMPLETIONS
if type brew &>/dev/null; then
    FPATH=$(brew --prefix)/share/zsh-completions:$FPATH
    autoload -Uz compinit
    compinit
fi

## OPTIONAL: .NET COMPLETIONS
_dotnet_zsh_complete()
{
  local completions=("$(dotnet complete "$words")")
  reply=( "${(ps:\n:)completions}" )
}
compctl -K _dotnet_zsh_complete dotnet

## OPTIONAL: KUBERNETES AUTOCOMPLETE
source <(kubectl completion zsh)

## ENABLE JUMP
eval "$(jump shell)"

## OH MY POSH
eval "$(oh-my-posh --init --shell zsh --config '~/ohmyposhv3.json')"

## SYNTAX HIGHLIGHT - GOES AT THE END
## USE THE PATH SAVED FROM THE 4TH STEP
source /usr/local/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

As you can see on the OhMyPosh line, the configuration is being loaded from the specified path: --config '~/ohmyposhv3.json'. Adjust that if you want, and in the path chosen create the following json file:

{
    "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
    "blocks": [
        {
            "type": "prompt",
            "alignment": "left",
            "segments": [
                {
                    "type": "session",
                    "style": "diamond",
                    "leading_diamond": "\uE0B6",
                    "trailing_diamond": "",
                    "background": "#100e23",
                    "foreground": "#ffffff",
                    "properties": {
                        "template": "{{ .UserName }}"
                    }
                },
                {
                    "type": "kubectl",
                    "style": "powerline",
                    "powerline_symbol": "\uE0B0",
                    "foreground": "#000000",
                    "background": "#ffffff",
                    "properties": {
                        "template": "{{.Context}} {{.Namespace}}"
                    }
                },
                {
                    "type": "path",
                    "style": "powerline",
                    "powerline_symbol": "\uE0B0",
                    "foreground": "#100e23",
                    "background": "#91ddff",
                    "properties": {
                        "home_icon": "\uF7DB",
                        "folder_icon": "\uF115",
                        "folder_separator_icon": " \uE0B1 ",
                        "style": "mixed"
                    }
                },
                {
                    "type": "git",
                    "style": "powerline",
                    "powerline_symbol": "\uE0B0",
                    "foreground": "#193549",
                    "background_templates": [
                        "{{ if .Working.Changed }}#fffb38{{ else }}#95ffa4{{ end }}"
                    ],
                    "properties": {
                        "branch_icon": "\ue725",
                        "fetch_status": true,
                        "fetch_upstream_icon": true,
                        "template": "{{ .UpstreamIcon }}{{ .HEAD }}{{ .BranchStatus }}{{ if .Working.Changed }} \uF044 {{ .Working.String }}{{ end }}{{ if and (.Working.Changed) (.Staging.Changed) }} |{{ end }}{{ if .Staging.Changed }}\uF046 {{ .Staging.String }}{{ end }}"
                    }
                },
                {
                    "type": "exit",
                    "style": "powerline",
                    "powerline_symbol": "\uE0B0",
                    "foreground": "#ffffff",
                    "background": "#ff8080",
                    "properties": {
                        "template": "{{ .Text }}"
                    }
                }
            ]
        }
    ],
    "final_space": true
}

[Windows] Windows Terminal

So far, the default profile is configured to be Ubuntu, now you need to configure the font and the font size for that profile. The font should be the previously installed: CaskaydiaCove NF and the size is up to you (but I don’t see much anymore so I use 18px).

You can further customize the theme of the terminal so the background might be transparent, dark, etc.

[Mac] Iterm2

The default MacOS terminal does not support background colors for the segments defined on the OhMyPosh json file. Download iTerm2 instead and enjoy of vertical and horizontal splits as well of other useful features. You can install it with brew install --cask iterm2.

When you have finished the installation, configure the font to be CaskaydiaCove NF and the font size you want. For this, go to preferences (cmd + ,), profiles, default, text.

In order to make option + -> and option + <- go one word forward and backwards you need to follow the instructions here.

Kubernetes segment

The OhMyPosh json contains a segment for displaying the current Kubernetes cluster:

{
    "type": "kubectl",
    "style": "powerline",
    "powerline_symbol": "\uE0B0",
    "foreground": "#000000",
    "background": "#ffffff",
    "properties": {
        "template": "{{.Context}} {{.Namespace}}"
    }
},

In case there is no ~/.kube/config file created it will just avoid the segment. If you use Kubernetes you have to install the command line to make this work, execute: brew install kubernetes-cli.

Git segment

The OhMyPosh json also contains a git segment. In case you are not sure if it is installed, execute: brew install git.

[Windows] Installing git on Windows

The git command line installed for WSL is not visible for Windows. This needs to be fixed as OhMyPosh is trying to use the git.exe. To solve this, open a cmd terminal and execute: winget install -e --id Git.Git.

This is just for display purposes, as all the commits you are going to do with the terminal are going to go through the WSL one.

Done!

After finishing with the step above your terminal should be working correctly with the format displaying correctly as well.

You can stop reading now that your terminal is working, or continue reading for:

Sign git commits.
Configure Visual Studio Code.
Useful non-GUI applications
Useful GUI applications.

Sign git commits

Regardless of your operative system, you can customize your global git configuration and enable signed commits
. Follow the steps:

Execute brew install gnupg.
If you are on Mac, execute also: brew install pinentry-mac.

You can now follow the steps described here for generating a GPG key and adding it to Github.

In your terminal, create the file ~/.gitconfig. Here you can add your basic git user data and your GPG key ID, indicating that you always want to sign your commits:

[user]
    name = Pablo Morelli
    email = email@email.com
    signingKey = <SOME-KEY-ID>
[gpg]
    program = gpg
[commit]
    gpgsign = true
[credential]
    helper = store

You can also create the file ~/.gnupg/gpg-agent.conf to add customizations like avoiding the gpg agent to ask you for your GPG passphrase every time you commit with default-cache-ttl 3600.

Configure Visual Studio Code

Visual studio code is the default text editor and programming IDE for most of the developers nowadays. The way it allows one to configure both settings and keyboard shortcuts as a JSON makes it possible for developers to port configuration from a machine to other.

MacOS: Execute: brew install --cask visual-studio-code.
Windows: On a cmd terminal, execute: winget install -e --id Microsoft.VisualStudioCode.

Settings

Open VSCode and access the command pallette either with Cmd + Shift + P or Control + Shift + P. Write Open Settings (JSON) and replace the json with the following:

{
    "search.useIgnoreFiles": false,
    "terminal.integrated.defaultProfile.osx": "zsh",
    "terminal.integrated.defaultProfile.windows": "Ubuntu (WSL)",
    "terminal.integrated.fontFamily": "CaskaydiaCove NF",
    "terminal.integrated.fontSize": 18,
    "terminal.integrated.copyOnSelection": true,
    "files.trimTrailingWhitespace": true,
    "files.insertFinalNewline": true,
    "files.trimFinalNewlines": true,
    "editor.fontLigatures": true,
    "editor.fontSize": 18,
    "editor.fontFamily": "CaskaydiaCove NF",
    "editor.formatOnSave": true,
    "diffEditor.ignoreTrimWhitespace": false,
    "explorer.confirmDelete": false,
    "go.formatTool": "goimports",
    "go.useLanguageServer": true,
    "go.toolsManagement.autoUpdate": true,
    "go.lintTool": "golangci-lint",
    "go.buildTags": "integration",
    "workbench.iconTheme": "material-icon-theme",
    "extensions.ignoreRecommendations": false,
    "window.zoomLevel": 1,
    "security.workspace.trust.untrustedFiles": "open",
    "liveshare.presence": true,
    "go.testEnvFile": "${workspaceFolder}/local.env"
}

Both terminal.integrated.defaultProfile.osx and terminal.integrated.defaultProfile.windows can coexist, but remove the one that does not apply to your environment if you don’t like having both.

Feel free to remove workbench.iconTheme if you do not wish to install the Material Icon Theme extension described on the section below, and same for the liveshare.presence in case you do not wish to install it either.

The terminal.integrated.fontFamily should be the CaskaydiaCove NF as configured on iTerm2 / Windows Terminal; but feel free to change your editor.fontFamily as you see fit. Also feel free to change the font size on both parts.

All the go.* settings might not be needed for you if you don’t plan using Go, so you can remove them.

Keyboard shortcuts

This is very opinionated, but I am used to two things:

Going back to a previous tab using cmd/ctrl + -, instead of zooming out a window.
Getting the autocomplete suggestions to prompt when I press cmd/ctrl + enter instead of space.

Open the command pallette once again and write Open Keyboard Shortcuts (JSON), replace the json with the one shown below. If you are using Windows replace cmd with ctrl.

[
    {
        "key": "cmd+-",
        "command": "workbench.action.navigateBack"
    },
    {
        "key": "cmd+[Enter]",
        "command": "editor.action.quickFix",
        "when": "editorHasCodeActionsProvider && editorTextFocus && !editorReadonly"
    },
]

Extensions

Go to the extensions tab and add Material Icon Theme and Live Share. Optionally, you can find below other extensions I use:

C#: Lint and syntax support.
C# Extensions: Useful right click actions such as create class, etc.
Code Spell Checker: Good for not native english speakers.
Diff: Shows the difference between two files.
Go: Lint and syntax support.
HashiCorp Terraform: Lint and syntax support.
String Manipulation: Provides functionality like reversing a word, etc.
Trailing Spaces: Highlights trailing spaces at the end of each line.
vscode-base64: Decode and encode utility.

Useful non-GUI applications

Below you can find some utilities that I often use and are compatible with all the operative systems. Install the ones you need.

Programming languages

brew install go.
brew install golangci-lint: Linter for golang.
brew install python@3.9.
brew install --cask dotnet-sdk: Only for MacOS.

Installing .NET on Windows (and WSL):

On a cmd terminal, execute: winget install -e --id Microsoft.dotnet.
For WSL follow the steps here.

Docker

Mac: brew install --cask docker.
Windows: On a cmd terminal execute: winget install -e --id Docker.DockerDesktop. Make sure to enable WSL 2 while installing it, in case it never prompt check on preferences that Use the WSL 2 based engine is enabled.

For both OS, go to preferences and tick the Use Docker Compose V2 box, so you can now use docker compose instead of the old docker-compose.

Kubernetes related

brew tap johanhaleby/kubetail && brew install kubetail: Displays the output of all containers sharing names or labels.
brew install istioctl: Istio command line utility.
brew install minikube: Your own Kubernetes cluster.

Other utilities

brew install git-crypt: Commit encrypted secrets in repositories.
brew install hugo: The framework used to build this blog.
brew install vegeta: Load testing utility for HTTP.
brew install yq: Manipulate yaml files.
brew install libpq: Adds psql to execute postgres database related commands.
brew install terraform: Infrastructure as a code utility.

Ngrok

Reverse proxy utility for testing localhost callbacks from chat bots or others related.

Mac: brew install -cask ngrok.
Windows: Execute on the WSL the download Linux steps via apt.

Useful GUI applications

MacOS:

brew install --cask slack.
brew install --cask whatsapp.
brew install --cask postman: Suite for testing HTTP requests.
brew install --cask dbeaver-community: Visual interface for database querying.

Windows, on a cmd terminal:

winget install -e --id SlackTechnologies.Slack.
winget install -e --id WhatsApp.WhatsApp.
winget install -e --id Postman.Postman.
winget install -e --id dbeaver.dbeaver.
winget install -e --id 7zip.7zip: If you need to decompress .rar.

Closing line

If you are setting up your computer from zero, a nice reminder:

Change OS appearance to dark theme, which is mandatory for developers.
Make your browser use a password manager, Privacy Badge, Adblock and Gmail Checker Plus.
Here you have a nice wallpaper I like.
For Windows, download the nice OSX icons for the mouse.

Источник

After customization, the terminal will look something like this:

Pre-requisites:

You must have WSL or WSL2 installed in your Windows 10 PC. For installation process, you can refer the official docs or watch this video by David Combal.
You must have the Windows Terminal or Windows Terminal Preview version installed. The easiest and recommended way to download it is from the Microsoft Store. I prefer to use the preview version as it has more features 😁(but may have some bugs).

Initial steps

Open up the Windows Terminal.
Open up Ubuntu (or any distro you have installed) in the Windows terminal by clicking on the down arrow next to the + icon.

Run the following command to check the version of the distro you have installed.

lsb_release -a

Enter fullscreen mode

Exit fullscreen mode

If everything worked fine, your distro name and version must be displayed.

(Optional but best practice) Run the following command to update your Ubuntu packages. For the other distros, run their respective commands.

sudo apt update && sudo apt upgrade -y && sudo apt autoremove && sudo apt autoclean

Enter fullscreen mode

Exit fullscreen mode

Install zsh shell

Run the command:

sudo apt install zsh

Enter fullscreen mode

Exit fullscreen mode

To check if zsh if installed, run:

zsh --version

Enter fullscreen mode

Exit fullscreen mode

You must see the version of zsh shell you have installed.

Set zsh as the default login shell by running the following command:

sudo usermod -s /usr/bin/zsh $(whoami)

Enter fullscreen mode

Exit fullscreen mode

Restart you computer and you must see zsh as the default login shell. 😀

Install oh-my-zsh

There are a ton of other frameworks for zsh shell like prezto, antigen, etc. My favorite is oh-my-zsh, but you can also try the other ones.

Run the command:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Enter fullscreen mode

Exit fullscreen mode

Yaay! It’s as easy as that.
You can configure the zsh shell by making changes in the ~/.zshrc shell. This file runs every time we open the z shell just like the .bashrc file runs every time we open the bash shell.
With the help of oh-my-zsh, a lot of cool plugins can be installed to increase your productivity. Here is a guide for installing some useful oh-my-zsh plugins.

Change settings in windows terminal

In the windows terminal, open Settings by pressing Ctrl + ,. This should open the settings.json file in your default editor (Mine is VS Code).
(Optional) To make Ubuntu as your default profile, copy the guid number from the list.

and paste it at the top in the defaultProfile property.

Next time you open Windows Terminal, Ubuntu must be the default profile opened.

Download the Cascadia Code PL and set it as a default fontFace.
(Note: Instead of Cascadia Code PL, you can install and apply one of the Nerd fonts from this website)

Set the useAcrylic and acrylicOpacity properties to add a beautiful opacity to your terminal.

If it isn’t working, check if Transparency Effects is checked in Settings > Personaliation > Colors.

If you want to have a look at my full settings, here it is.
For all the available settings in the terminal, refer the official docs.

Install Powerline fonts

Run the following command:

sudo apt install fonts-powerline

Enter fullscreen mode

Exit fullscreen mode

This must install powerline fonts so that weird symbols don’t appear in the terminal.
(You can also install one of Nerd Fonts and apply it to your terminal settings).

Install Powerlevel10k theme

Run the command:

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

Enter fullscreen mode

Exit fullscreen mode

Open ~/.zshrc file in your favorite editor. For VS Code, run the command code ~/.zshrc. Add the line ZSH_THEME="powerlevel10k/powerlevel10k" and save.

Run the command source ~/.zshrc to apply the changes made in .zshrc file.
Configure the p10k settings according to your liking :).
(Optional) After all this, the terminal should look pretty awesome. But even more customization can be made by opening the file ~/.p10k.zsh file. Check their offical github page for more info.

Done!! Your terminal must look similar to this:

Thank you for reading :). Please do share your feedback ✌

Источник

Есть люди, которые большинство рабочего времени проводят в консоли, есть те, кто пользуются терминалом при необходимости, запуская что-то по инструкциям. Но я думаю, что каждый айтишник, будь он разработчиком, сисадмином, сетевым инженером, или даже 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 в процессе постоянного усовершенствования конфигов и поиска удобных тулов для работы.

Windows Subsystem for Linux (WSL) 2

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

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

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

Стоит иметь ввиду, что до билда версии 18995 WSL имеет баг при работе с файлами на примонтированных дисках 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 PowerShell дистрибутива WSL на примере Kali Linux). При предпочтении Ubuntu или другого дистрибутива Linux из доступных, заменить ссылку и названия на соответствующие.

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

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | 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), либо дальше выполнить в 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.», значит у вас стоит билд, в котором проявляется очередной (уже исправленный в последних релизах) баг. Как обычно, есть воркэраунд, либо использовать дистрибутив Ubuntu, с ним у меня не было проблем на той же не последней версии билда.

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

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

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

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

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.

Сделать ребут дистрибутива можно из 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 строго не рекомендовали изменять Linux файлы из Windows. В новой версии WSL доступ к ФС на виртуальном диске обеспечивается с помощью файлового сервера Plan 9 Filesystem Protocol.

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

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

Изначально, у WSL были проблемы с тем, чтобы высвобождать ресурсы после использования RAM. В билде 19013 эту проблему решили. Если запускать ресурсоёмкие задачи (например, сборка rust приложения) можно заметить, что процесс Vmmem будет в топе Диспетчера задач, однако потребление памяти значительно снизилось в последних версиях 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 до своего VPS, нужно запустить 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 в Хроме появляется возможность использовать доступ к сайтам через IPv6.

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

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

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

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

Так как в WSL не работает Systemd, есть проблема с автозапуском сервисов со стартом системы. Есть несколько способов настроить автостарт ssh сервера в WSL, самый простой — это создать задачу в Task Scheduler, где прописать команду старта сервера. В интернете можно найти разные инструкцииавтозапуска через скрипты 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).

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

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

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

Triggers: At startup Actions: Start a program ____Program: "%ProgramFiles%\VcXsrv\vcxsrv.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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шрифты

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

Fira Code
Hack
любые другие патченые шрифты

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

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

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

Заключение

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

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

References

Announcing WSL 2 (devblogs.microsoft.com)
WSL 2 is now available in Windows Insiders (devblogs.microsoft.com)
Memory Reclaim in the Windows Subsystem for Linux 2 (devblogs.microsoft.com)
Automatically Configuring WSL (devblogs.microsoft.com)
wsl2-tutorial (github.com)
Terminal v1.0 Roadmap (github.com)
Editing Windows Terminal JSON Settings (github.com)

Источник