Windows Terminal як професіонал: профілі, шрифти та скорочення

Було корисно?

Windows Terminal — це місце, куди йдуть добрі наміри, щоб загинути: десяток вкладок, три шелли, якийсь загадковий шрифт і скорочення, що наче створені колегіально. Потім дзвонить пейджер, і ви намагаєтеся вставити однорядкову команду в невірну панель, поки курсор зникає в миготливому прямокутнику сорому.

Можна зробити краще. Це посібник «зупинити витік часу»: дисципліновані профілі, передбачувані шрифти та скорочення, яким можна довіряти в стресі. А також як швидко діагностувати, чому Terminal здається повільним, перш ніж ви знову звинуватите мережу.

Практична модель мислення: Terminal — це хост, профілі — контракти

Думайте про Windows Terminal як про ввічливий мультиплексор з власними переконаннями. Він не «є» PowerShell чи WSL; він їх хостить. Ваше завдання — визначити контракти: який шелл запускається, з якої робочої директорії, з яким оточенням, яким шрифтом та прив’язками клавіш, і з якими запобіжними механізмами.

Якщо ви ставитеся до профілів як до декорації («я просто клікну в випадаючому меню»), ви отримаєте ту саму помилку, що й у недбалому SRE-runbook: невизначеність під тиском. Профілі повинні відповідати на ці питання, не змушуючи вас думати:

  • В якому я середовищі: prod, staging, особисте, on-call?
  • Яку ідентичність я використовую: локальний користувач, адмін, SSH-ключ A чи B?
  • Яка стандартна директорія та стандартний тулчейн?
  • Які запобіжні функції ввімкнені: підтвердження, змонтовані тільки для читання томи, попередження?

Це не питання естетики. Це операційна коректність. Терминал — це кабіна пілота. Пронумеруйте й підпишіть вимикачі.

Цікаві факти та контекст, які можна використовувати в дискусіях

  1. Windows Terminal відносно новий: Microsoft представила його публічно у 2019 році, і він став основним за замовчуванням на багатьох Windows 11 конфігураціях пізніше. Сенс у тому, що він ще еволюціонує; ваша пам’ять «раніше працювало» може залежати від версії.
  2. ConPTY був переломним моментом: Windows Console Pseudo-terminal (ConPTY) дозволив сучасним термінальним додаткам спілкуватися з консольними програмами більш у Unix-подібний спосіб. До того, емулювання терміналу в Windows було… закалювальним досвідом.
  3. Старий Console Host (conhost.exe) все ще існує: Windows Terminal може хостити класичні консольні додатки, але вони можуть поводитися так, ніби були створені для іншої епохи — бо так воно й є.
  4. PowerShell має дві особистості: Windows PowerShell (5.1) — спадкова в комплекті версія; PowerShell (7+) — кросплатформений і активно розвивається. Змішувати їх без маркування — уникненний самостріл.
  5. WT підтримує кілька рендерерів: сучасне GPU-прискорене відображення тексту може бути швидким, але також виявляє проблеми зі шрифтами та гліфами, яких ви не бачили в старих консолях.
  6. Вкладки та панелі — не просто прикраса інтерфейсу: вони зменшують контекстні переключення. Якщо використовувати погано, вони створюють помилки «де я?»; якщо добре — роблять реагування на інциденти повторюваним процесом.
  7. Налаштування перейшли від JSON-only: ранній Windows Terminal конфігурувався переважно через settings.json; тепер є UI, але JSON залишається джерелом правди для відтворюваних налаштувань.
  8. NERD fonts — це не «тема»: це патчовані шрифти з додатковими гліфами. Якщо вам ці гліфи не потрібні — не використовуйте такий шрифт і позбудетесь цілої категорії проблем відображення.

Профілі: робіть середовища навмисно нудними

Правила проєктування профілів, що запобігають реальним помилкам

Ось правила, які я застосовую в командах:

  • Називайте профілі як інфраструктуру: «WSL Ubuntu» підходить для ноутбука. Для виробництва: «WSL: ubuntu (staging tooling)», «PowerShell 7 (admin)», «SSH: bastion (prod-readonly)».
  • Стартова директорія — це політика, а не вподобання. Починайте з безпечного місця з відомими скриптами, а не з останньої випадкової директорії, в яку ви cd.
  • Зробіть prod візуально відмінним. Інша кольорова схема, заголовок вкладки і навіть інший стиль курсора. Ви хочете, щоб мозок це помічав.
  • Перевага явним командним рядкам замість «що там знайде система». Зафіксуйте pwsh.exe vs powershell.exe і вкажіть WSL-дистрибутиви за іменем.
  • Використовуйте одне місце для автоматизації: тримайте профільні скрипти в керованих версіях dotfiles, якщо можливо. Місцева магія — шлях до сніжинок.

Структура налаштувань, що залишається підтримуваною

Налаштування Windows Terminal — це злиття значень за замовчуванням і ваших переваг. Вам не потрібно переписувати світ. Потрібно визначити: default profile, список профілів, зовнішній вигляд за замовчуванням і прив’язки. Ставтеся до цього як до infrastructure-as-code: мінімально, явно, підлягає рецензії.

Ключові поля, які варто розуміти і використовувати свідомо:

  • defaultProfile: що запускається при відкритті Terminal. Якщо ви цього не вкажете, після інсталяцій і оновлень будуть сюрпризи.
  • profiles.list: ваш кураторський перелік профілів.
  • guid: стабільна ідентичність профілю. Якщо редагувати лише за іменем, зрештою зіткнетеся з автоматично згенерованими конфліктами.
  • commandline: що саме стартує. Віддавайте перевагу явним шляхам для не вбудованих шеллів.
  • startingDirectory: перше місце, куди потрапляє шелл. Нудьга — добра.
  • tabTitle і name: одне — мітка у відображенні, інше — селектор профілю. Використовуйте обидва.
  • colorScheme, cursorShape, font: візуальні запобіжники.

Шаблони профілів, що працюють у продакшні

Шаблон 1: «Admin» — окремий профіль. Не звикайте до «Run as administrator» як до звички. Потрібен профіль, що чітко каже «ви тримаєте бензопилу». Інша іконка, інша схема, інший заголовок. Використовуйте його свідомо.

Шаблон 2: «Prod» за замовчуванням тільки для читання. Якщо ваш робочий процес це витримає, використовуйте SSH-профіль, що приводить на бастіон з обмеженими правами, або шелл, який експортує змінні-огорожі. Зробіть «break glass» окремим профілем з очевидною назвою.

Шаблон 3: «Tooling» — по контексту. Якщо у вас є Kubernetes-контексти, AWS-профілі або різні SSH-конфіги, не завантажуйте все одразу при старті шелла. Створіть профілі, що завантажують тільки потрібне. Час старту має значення; так само як і коректність.

Шрифти: читабельність, лігатури і тиранія відсутніх гліфів

Вибирайте шрифт так, як обираєте дашборд моніторингу

Шрифт терміналу — це не модний аксесуар. Це інтерфейс. Від вибору шрифту залежить:

  • Як швидко ви помітите опечатку в команді, яка може щось видалити.
  • Чи правильно відображаються символи для малювання коробок (таблиці, tmux-подібний UI, CLI).
  • Чи показуються символи Powerline або Nerd Font як квадратики.
  • Чи має проблеми GPU-рендерер (рідко, але реально на старих системах).

Мій упереджений рада:

  • За замовчуванням обирайте Cascadia Mono або інший чистий моноширинний шрифт, що добре рендериться в Windows. Тримайте його нудним, поки не буде причини змінювати.
  • Використовуйте Nerd Font лише якщо потрібні гліфи. Якщо тема вашого prompt залежить від іконок — гаразд. Якщо ви просто хочете почуватися сучасно — ні. Відсутні гліфи створюють операційний шум.
  • Вимкніть лігатури, якщо у вас немає сильної переваги. Лігатури можуть змусити оператори читатися некоректно — наприклад !=, => або == у деяких шрифтах. Коли ви втомлені, вам потрібно буквальне відображення.

Короткий жарт: лігатури — як кофеїн: чудово, поки не зрозумієш, що вони ховають правду і тепер не можеш спати.

Проблеми зі шрифтами, що виглядають як «система проклята»

Якщо ви бачите квадратики, знаки питання або неправильно вирівняні символи prompt, це майже завжди одне з наступного:

  • Ви обрали шрифт без потрібних Unicode-гліфів.
  • Ваш шелл видає символи Powerline, але шрифт не патчений.
  • Використовується fallback-шрифт непослідовно, бо первинний шрифт не має символів.
  • Метрики шрифту спричиняють проблеми з висотою рядка; курсор не вирівнюється або текст перекривається.

Виправлення рідко — «перевстановіть Windows Terminal». Зазвичай це «оберіть шрифт, що відповідає вашому prompt».

Скорочення: м’язова пам’ять перемагає креатив

Прив’язуйте клавіші для реагування на інциденти, а не для забави

Прив’язки клавіш — це те, де хороші користувачі терміналу стають швидкими користувачами. Але випадкові скорочення гірші за відсутність; вони дають фальшиву впевненість. Виберіть невелику множину і стандартизуйте їх на всіх машинах.

Моя рекомендована філософія прив’язок:

  • Зберігайте дефолти, коли вони розумні. За замовчуванням Windows Terminal здебільшого адекватний для вкладок/панелей.
  • Стандартизujte розділення панелей на ті ж клавіші, що ви використовуєте в інших мультиплексорах, якщо ви в них живете. Послідовність краще за новизну.
  • Зробіть «копію» і «вставку» передбачуваними. Вирішіть, чи автоматично копіюється виділення, чи правий клік вставляє, і що робить Ctrl+V. Потім зафіксуйте це.
  • Майте поведінку «паніки закриття», що підтягує підтвердження. Випадкове закриття невірної вкладки під час інциденту — особливий вид болю.

Вкладки, панелі і режим «не та панель»

Панелі чудові, поки ні. Основна операційна помилка — виконання команди в неправильній панелі. Лікування не «будь уважніший». Лікування таке:

  • Відмінні заголовки вкладок, що включають маркери середовища.
  • Кольорові схеми по середовищу.
  • Клавіатурні скорочення для «фокусувати панель», які легкі і послідовні.
  • Стартові команди, що встановлюють видимий prompt або заголовок для кожного середовища.

Практичні завдання: 12+ перевірок, команд, виводів, рішень

Це реальні завдання, які можна виконати на Windows з встановленим WSL. Я використовую WSL, бо він дає консистентний шелл для команд і виводів, і сучасні користувачі Windows Terminal зазвичай його мають. Кожне завдання включає: команду, що означає вивід, і рішення, яке ви приймаєте.

Завдання 1: Перевірити, що Windows Terminal встановлено і визначити пакет

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-AppxPackage Microsoft.WindowsTerminal | Select-Object Name, Version, PackageFullName"
Name                          Version      PackageFullName
----                          -------      ---------------
Microsoft.WindowsTerminal     1.21.3471.0  Microsoft.WindowsTerminal_1.21.3471.0_x64__8wekyb3d8bbwe

Що це означає: Ви бачите встановлений пакет Windows Terminal і його версію.

Рішення: Якщо його немає або версія дуже стара, припиніть налагодження налаштувань. Оновіть спочатку; поведінка змінюється між версіями.

Завдання 2: Знайти файл налаштувань, який ви насправді редагуєте

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Test-Path $p; $p"
True
C:\Users\cr0x\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

Що це означає: Файл налаштувань існує в канонічному розташуванні для пакету.

Рішення: Якщо Test-Path повертає False, можливо у вас інший канал інсталяції або файл ще не створено. Відкрийте Terminal один раз або знайдіть правильну папку пакета.

Завдання 3: Перевірити, чи settings.json валідний JSON (швидко знайти зайві коми)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Get-Content $p -Raw | ConvertFrom-Json | Out-Null; 'JSON OK'"
JSON OK

Що це означає: Ваш файл налаштувань парситься. Якщо ні, Terminal може мовчки ігнорувати частини або повертатися до значень за замовчуванням залежно від помилки.

Рішення: Виправте JSON перед будь-якими іншими діями. Невалідний JSON робить інші симптоми випадковими.

Завдання 4: Перелічити профілі та їх GUID, щоб уникнути редагування невірного

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; $j.profiles.list | Select-Object name, guid, source"
name                    guid                                   source
----                    ----                                   ------
PowerShell              {61c54bbd-c2c6-5271-96e7-009a87ff44bf} Windows.Terminal.PowershellCore
Windows PowerShell      {0caa0dad-35be-5f56-a8ff-afceeeaa6101} Windows.Terminal.Powershell
Ubuntu                  {2c4de342-38b7-51cf-b940-2309a097f518} Windows.Terminal.Wsl

Що це означає: У вас декілька варіантів PowerShell плюс WSL. GUID — стабільні дескриптори.

Рішення: Виберіть той, який хочете змінити, і адресуйте за GUID, а не вгадуванням.

Завдання 5: Перевірити, який профіль зараз встановлено за замовчуванням

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; (Get-Content $p -Raw | ConvertFrom-Json).defaultProfile"
{61c54bbd-c2c6-5271-96e7-009a87ff44bf}

Що це означає: Terminal відкриватиме PowerShell 7 за замовчуванням (у цьому прикладі GUID).

Рішення: Встановіть defaultProfile явно, щоб він відповідав вашому найбільш безпечному робочому потоку. Не залишайте це на волю випадку.

Завдання 6: Перевірити, звідки профіль стартує (startingDirectory)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; ($j.profiles.list | Where-Object name -eq 'PowerShell').startingDirectory"
C:\Users\cr0x

Що це означає: Ваш PowerShell-профіль відкривається в домашній теці користувача.

Рішення: Якщо ви робите операційні завдання, розгляньте старт у виділеній теці, наприклад C:\ops або в репозиторії зі скриптами і нотатками. Менше «де цей файл?» моментів.

Завдання 7: Визначити, який шелл ви фактично запускаєте (pwsh vs powershell)

cr0x@server:~$ powershell.exe -NoProfile -Command "$PSVersionTable.PSVersion.ToString()"
5.1.22621.2506

Що це означає: Ця команда виконана у Windows PowerShell 5.1 (бо ми викликали powershell.exe).

Рішення: Якщо думаєте, що ви в PowerShell 7, але насправді ні — модулі і TLS за замовчуванням можуть відрізнятися. Використовуйте pwsh.exe явно в профілях, що його потребують.

Завдання 8: Підтвердити наявність PowerShell 7 (і його шлях)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Command pwsh | Select-Object Source, Version"
Source                         Version
------                         -------
C:\Program Files\PowerShell\7\pwsh.exe 7.4.1

Що це означає: PowerShell 7 встановлено і доступний.

Рішення: Вказуйте командлінь профілю PowerShell 7 безпосередньо на цей шлях, щоб уникнути дивних випадків з PATH.

Завдання 9: Перелічити встановлені WSL-дистрибутиви (і вибрати стабільну ціль)

cr0x@server:~$ powershell.exe -NoProfile -Command "wsl.exe -l -v"
  NAME            STATE           VERSION
* Ubuntu          Running         2
  Debian          Stopped         2

Що це означає: WSL має Ubuntu і Debian. Ubuntu — за замовчуванням (зірочка) і наразі запущений.

Рішення: Якщо у вас кілька дистроїв, зробіть окремі профілі, зафіксувавши wsl.exe -d Ubuntu тощо. Не покладайтеся на дистрибутив за замовчуванням.

Завдання 10: Заміряти час старту шелла, щоб виявити «повільні» профіль-скрипти

cr0x@server:~$ powershell.exe -NoProfile -Command "Measure-Command { pwsh.exe -NoProfile -Command \"exit\" } | Select-Object TotalMilliseconds"
TotalMilliseconds
-----------------
142.8817

Що це означає: Запуск PowerShell 7 без завантаження профілю швидкий.

Рішення: Якщо -NoProfile швидкий, а звичайний старт повільний — винен ваш профіль-скрипт. Виправляйте dotfiles, не Terminal.

Завдання 11: Визначити, чи ваш PowerShell-профіль робить дорогі операції

cr0x@server:~$ pwsh.exe -NoProfile -Command '$PROFILE; Test-Path $PROFILE; Get-Content $PROFILE -TotalCount 20'
C:\Users\cr0x\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
True
Import-Module posh-git
Import-Module oh-my-posh
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression

Що це означає: Профіль імпортує модулі і ініціалізує тему prompt. Це може бути повільно, особливо якщо модулі знаходяться на мережевому шляху або антивірус агресивний.

Рішення: Кешуйте ініціалізацію prompt, завантажуйте модулі ліниво або створіть «мінімальний» профіль для on-call.

Завдання 12: Перевірити, чи випадково не підключаються мережеві домашні шляхи (країна латентності)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Item env:USERPROFILE, env:HOMEDRIVE, env:HOMEPATH, env:HOMESHARE | Format-Table -AutoSize"
Name        Value
----        -----
USERPROFILE C:\Users\cr0x
HOMEDRIVE   C:
HOMEPATH    \Users\cr0x
HOMESHARE

Що це означає: Ніякий мережевий домашній шар не налаштовано (у цьому прикладі).

Рішення: Якщо HOMESHARE вказує на UNC-путь, очікуйте повільні prompt, якщо ваш профіль торкається домашньої теки під час старту.

Завдання 13: Перевірити наявність шрифту (зловити «я вказав шрифт, якого немає»)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' | Select-String -Pattern 'Cascadia|Nerd|Caskaydia' -SimpleMatch"
Cascadia Mono (TrueType)    REG_SZ    CascadiaMono.ttf
Cascadia Code (TrueType)    REG_SZ    CascadiaCode.ttf

Що це означає: Cascadia-шрифти присутні. Ваші налаштування, що посилаються на них, мають працювати.

Рішення: Якщо ім’я шрифту відсутнє — встановіть його або припиніть посилатися на нього. Terminal не знайде шрифт, якого не існує.

Завдання 14: Виявити конфлікти прив’язок, проглянувши дубльовані клавіші

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $raw = Get-Content $p -Raw; ($raw | Select-String -Pattern '\"keys\"' | Measure-Object).Count"
24

Що це означає: У файлі є 24 записи прив’язок клавіш (пошук по слову "keys").

Рішення: Якщо ви експериментували, ймовірно є колізії. Консолідуйте. Краща множина прив’язок — та, яку ви можете пояснити колезі.

Завдання 15: Перевірити, чи використовується ваш SSH-конфіг (правильність профілю)

cr0x@server:~$ wsl.exe -d Ubuntu -- bash -lc "grep -nE '^(Host|  HostName|  User|  IdentityFile)' ~/.ssh/config | head -n 20"
1:Host bastion-prod
2:  HostName bastion.prod.example
3:  User ops
4:  IdentityFile ~/.ssh/id_ed25519_ops

Що це означає: Ваш SSH-конфіг визначає bastion-хост з певним ключем.

Рішення: Створіть профіль Terminal, що запускає ssh bastion-prod, щоб оператори не друкували хости о 3 ранку.

Швидкий план діагностики: що перевіряти першим/другим/третім

Це швидка тріаж-карта, коли Windows Terminal «здається повільним», введення тексту відстає, вкладки довго відкриваються або копіювання/вставка поводяться непослідовно. Ви полюєте на вузьке місце, а не на відчуття.

По-перше: ізолюйте, чи проблема в Terminal, чи в шеллі

  1. Запустіть шелл без профілю (PowerShell: pwsh -NoProfile). Якщо швидко — винні скрипти профілю.
  2. Запустіть просту сесію типу cmd (або мінімальний PowerShell-профіль). Якщо UI Terminal все ще гальмує — дивіться рендеринг/шрифт і фактори GPU/RDP.
  3. Спробуйте WSL з мінімальною командою (наприклад wsl -d Ubuntu -- echo ok). Якщо це повільно — задіяно старт WSL або інтеграція файлової системи.

По-друге: перевірте три найпоширеніші причини витрат часу

  1. Скрипти профілю, що лізуть в мережу: імпорти модулів з UNC-путів, git status у великих репозиторіях, теми prompt, що читають файли через синхронізовані папки.
  2. Антивірусне сканування: особливо в директоріях модулів або домашніх теках в OneDrive/синхронізованих шляхах.
  3. Поведінка fallback-шрифтів: патчені шрифти або відсутні гліфи можуть спричиняти глюки відображення і невідповідність курсора.

По-третє: визначте множники, специфічні для середовища

  1. Сесії віддаленого робочого столу: графічне прискорення і інтеграція буфера обміну поводяться інакше; можете бачити затримки введення, яких немає локально.
  2. Великий буфер прокрутки та важкий вивід: деякі CLI виводять тисячі рядків; відображення стає вузьким місцем. Зменшіть вивід або налаштуйте прокрутку.
  3. Крайові випадки ConPTY: старі консольні додатки можуть поводитися неправильно; спробуйте запустити їх у класичній консолі для перевірки.

Якщо робити це по порядку — ви припините гадати. Ви також припините «оптимізувати» не те, що потрібно.

Типові помилки: симптом → корінна причина → виправлення

1) «Мій prompt повільний; Terminal має бути повільним.»

Симптоми: Нові вкладки відкриваються за секунди. Курсор з’являється, але ви кілька секунд не можете вводити. Під час старту стрибки CPU.

Корінна причина: Ваш профіль шелла робить дорогі операції: git status у великих теках, імпорт модулів, ініціалізація теми, мережеві перевірки, виклики cloud CLI.

Виправлення: Створіть два профілі: «мінімальний» (on-call) з -NoProfile або полегшеним профілем, і «повний» для щоденної розробки. Завантажуйте модулі ліниво і уникайте мережевих викликів у шляху prompt.

2) «Мої іконки — квадрати; Windows Terminal зламався.»

Симптоми: Роздільники Powerline відображаються як tofu (□). Малювання коробок виглядає неправильно. Вирівнювання prompt збивається.

Корінна причина: Шрифт не має гліфів або fallback-шрифти використовуються непослідовно. Іноді ви вказали ім’я шрифту, який не встановлено.

Виправлення: Встановіть правильний шрифт і вказуйте його точну назву, або припиніть використовувати іконкові prompt. Також налаштуйте lineHeight, якщо потрібно уникнути перекриття.

3) «Копіювання/вставка непослідовні і я постійно вставляю в prod.»

Симптоми: Виділення іноді копіює, іноді ні. Правий клік іноді вставляє. Ctrl+V поводиться інакше між панелями/додатками.

Корінна причина: Змішані налаштування між Terminal, шеллом і віддаленими сесіями; плюс м’язова пам’ять з інших терміналів.

Виправлення: Визначте політику і зафіксуйте її в налаштуваннях: послідовні прив’язки для копіювання/вставки і поведінку виділення. Зробіть prod-профіль візуально гучним, щоб очі помічали «невірну панель».

4) «Вкладки дублюються або профілі змінилися після оновлення.»

Симптоми: З’являються нові профілі за замовчуванням; ваші ретельно названі загублені; default profile змінився.

Корінна причина: Автоматично згенеровані профілі від встановлених шеллів; ваш defaultProfile не був явно зафіксований; ви покладалися на ім’я, а не на GUID.

Виправлення: Встановіть defaultProfile на потрібний GUID. Кураторьте profiles.list. Видаліть або сховайте автоматично згенеровані профілі, які не хочете показувати.

5) «WSL стартує, але операції з файлами повільні.»

Симптоми: git status повільний. Встановлення Node триває вічно. Все в /mnt/c відчувається повільним.

Корінна причина: Ви виконуєте Linux-накшовані навантаження на Windows-файловій системі (/mnt/c), яка повільніша за WSL ext4 для задач з великою кількістю метаданих.

Виправлення: Тримайте репозиторії у файловій системі дистрибутиву WSL (наприклад ~/src). Використовуйте профіль, що стартує там.

6) «Клавішні скорочення не працюють у віддалених сесіях.»

Симптоми: Скорочення для сплітів панелей не спрацьовують; комбінації клавіш перехоплюються.

Корінна причина: Мапінг клавіш в RDP/клієнті, системні хоткеї або перехоплення додатком.

Виправлення: Перепризначте конфліктні комбінації в Terminal і обирайте скорочення, які переживуть ваше віддалене оточення. Тестуйте шлях, яким реально користуються оператори.

Три корпоративні міні-історії (бо реальність любить сюжетні повороти)

Міні-історія 1: Інцидент спричинений хибним припущенням

Вони мігрували конвеєр збірки і релізів з Windows PowerShell до PowerShell 7. Локально все виглядало добре. В Windows Terminal інженер мав профіль «PowerShell» і припустив, що це означає нову версію. Ім’я співпадало з його ментальною моделлю: PowerShell = сучасний.

Під час аварійного виправлення вони відкрили нову вкладку і запустили скрипт, що тягнув залежності з TLS за замовчуванням. На ноутбуці в pwsh воно працювало. На дзвінку по інциденту це впало в їх вкладці, бо фактично це був Windows PowerShell 5.1 з іншими значеннями за замовчуванням і поведінкою модулів. Повідомлення про помилку не було драматичним; воно було гірше: неоднозначним. Люди почали звинувачувати репозиторій артефактів.

Вони «виправили» це шляхом повторних спроб і тимчасового відключення перевірок, що неабияк непокоїло безпеку. Фікс був доставлений, але постінцидентний розбір не був приємним. Корінна причина не в репозиторії. Вона була в невірному профілі терміналу. Вкладка виглядала як усі інші вкладки.

Ремедіація була нудною і ефективною: явні назви профілів («PowerShell 7» vs «Windows PowerShell»), зафіксовані командні рядки і defaultProfile, встановлений по GUID. Вони також змінили заголовок вкладки, щоб включити PS7 або PS5. Після цього цей тип помилки припинив існувати. Не зменшився. Усунувся.

Міні-історія 2: Оптимізація, що відкотилася назад

Команда хотіла, щоб їхні prompt показували все: гілку git, статус dirty, Kubernetes-контекст, хмарний акаунт і номер інциденту. Виглядало круто в скріншотах і демо. Але це робило трохи роботи при кожному рендері prompt — при кожній команді, кожному Enter, кожному автозаповненні.

Щоб пришвидшити, вони додали кешування. Ідея хороша в теорії. Кеш жив у профілі користувача, який на корпоративних машинах синхронізувався або перенаправлявся. За нормальних умов все добре. За VPN-джитеру читання кешу ставало повільним, і раптом вводіння відчувалося як затримане. Люди звинуватили рендеринг Windows Terminal.

Проблема проявилася, коли інженер у час інциденту відкрив кілька панелей і намагався зменшити вивід, слідкуючи логи. Тема prompt постійно перевіряла мережевий контекст; кеш почав тріпати. Terminal був чуйним, шелл — ні, і оператор фактично боровся зі своїм власним prompt.

Вони відкотилися до мінімального prompt для ops-профілів: тільки гілка git, без мережевих перевірок, без хмарного контексту. Fancy-prompt лишили для dev-профілів. Оптимізація не була злочинцем; оптимізація не в тому місці була.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Інша організація мала звичку, що виглядала надмірною: вони підтримували у версійованому репозиторії фрагмент settings.json для on-call інженерів. Це не було обов’язковим, але наполегливо рекомендувалося. Фрагмент визначав невеликий набір профілів: «On-call PowerShell (minimal)», «WSL tooling», «SSH bastion (prod)» і «SSH bastion (staging)».

Prod-SSH профіль робив нудну, але корисну річ: гучний заголовок вкладки, рудувата кольорова схема і стартова команда, що друкувала короткий банер-попередження. Також він встановлював інший стиль курсора. Люди жартували над цим, поки це не врятувало від помилки.

Під час аварії інженер мав чотири панелі відкриті: запит метрик, підписування логів, SSH у staging і SSH у prod. Вони ледь не вставили команду для очищення тільки в staging в prod. Вони помітили форму курсора і заголовок вкладки в останню секунду. Без героїзму, без драми — просто запобіжник, що виконав свою роботу.

Постмортем був майже анти-кліматичним: «Ми ледь не зробили погано, але профіль терміналу змусив нас зупинитися.» Саме цього ви й прагнете. Надійність — це здебільшого відсутність захоплюючих історій.

Контрольні списки / покроковий план

План A: Побудувати здоровий набір профілів менше ніж за годину

  1. Перелікуйте ваші шелли: PowerShell 5.1, PowerShell 7, WSL-дистрибутиви, шаблони використання SSH.
  2. Створіть чотири базові профілі:
    • PowerShell 7 (щоденний)
    • PowerShell 7 (мінімальний / on-call)
    • WSL (tooling) зі стартом у ~/src
    • SSH: bastion (prod) з гучною візуалізацією
  3. Зафіксуйте defaultProfile на найбезпечнішій спільній опції (часто PS7 minimal).
  4. Оберіть один шрифт і дотримуйтеся його. Якщо мусите використовувати Nerd Fonts — робіть це свідомо і перевіряйте гліфи.
  5. Визначте 6–10 скорочень, якими ви дійсно користуватиметеся: нова вкладка, закрити вкладку (з підтвердженням), розділити панель, фокус панелі, пошук, копіювання, вставка.
  6. Перевірте сценарій «не та панель»: відкрийте prod/staging профілі поруч і переконайтеся, що одразу видно, яка яка.
  7. Після змін валідируйте JSON. Не довіряйте очам.

План B: Виправити повільність, не зламавши робочий процес

  1. Заміряйте: час запуску pwsh -NoProfile порівняно зі звичайним. Якщо є різниця — винні профіль-скрипти.
  2. Мінімізуйте: створіть мінімальний профіль і використовуйте його, коли латентність критична.
  3. Видаліть мережеві виклики з prompt і старту. Ніяких перевірок хмарного контексту, ніяких автооновлень, ніяких git status у великих репозиторіях за замовчуванням.
  4. Перевіряйте шрифт і рендеринг тільки після того, як доведено, що шелл стартує швидко.
  5. Стандартизувати: тримайте одну відому хорошу baseline settings. Дрейф — це шлях до «на моїй машині повільно» як командної гри.

План C: Зробити відтворюваним для всієї команди

  1. Визначте фрагмент baseline settings.json (профілі, схеми, прив’язки).
  2. Вирішіть, що персональне: фон, прозорість, експериментальні теми — тримайте це поза baseline.
  3. Документуйте контракт: що означає «On-call» профіль, що завантажує і чого навмисне не завантажує.
  4. Рецензуйте зміни, як код. Прив’язки та прод-візуалізації не повинні бути «як заманеться».

Одна ідея надійності, яку варто тримати в голові

Перефразована ідея (приписується John Allspaw): «Безкульові уроки працюють найкраще, коли ви фокусуєтеся на тому, як локальний контекст людей зробив їхні дії обґрунтованими в той момент.»

Помилки в терміналі часто — це помилки контексту: не та панель, не та ідентичність, не той шелл. Ваше завдання — зробити правильну дію легкою, а неправильну очевидною.

FAQ

1) Чи варто редагувати налаштування в UI чи в settings.json?

Використовуйте UI для швидких правок; JSON — для всього, що ви хочете відтворювати, рецензувати або відкатувати. Якщо ви піклуєтеся про консистентність, JSON — джерело правди.

2) Чому у мене кілька профілів PowerShell?

Бо, ймовірно, у вас встановлені і Windows PowerShell (5.1), і PowerShell 7, і Terminal може їх автодетектити. Перейменуйте їх чітко і зафіксуйте командні рядки, щоб завжди знати, що ви запускаєте.

3) Який найкращий шрифт?

Найкращий шрифт — той, який ви можете читати о 3 ранку і який правильно відображає ваші символи. Почніть з Cascadia Mono. Перейдіть на Nerd Font тільки якщо prompt дійсно потребує іконок.

4) Моя тема prompt виглядає круто, але повільна. Що робити?

Розділіть на два профілі: мінімальний ops-профіль і повний dev-профіль. Приберіть мережеві запити з рендеру prompt і уникайте дорогих git-операцій за замовчуванням.

5) Як припинити вставляти в неправильну панель?

Робіть середовища візуально відмінними (схема, заголовок, курсор). Призначте скорочення фокусування панелі, які легко вбити не думаючи. І робіть prod-профілі навмисно «гучними».

6) Чому WSL швидкий на Linux-шляху, але повільний в /mnt/c?

Тому що завдання з великою кількістю метаданих (git, npm, збірки з великою кількістю дрібних файлів) повільніші на Windows-монті /mnt/c. Розміщуйте репозиторії у файловій системі WSL і стартуйте WSL-профіль там.

7) Чому мій default profile змінився?

Оновлення і нові шелли можуть додавати профілі. Якщо ви не зафіксували defaultProfile явно по GUID, ви залишили рішення випадку. Зафіксуйте його.

8) Як зберегти скорочення послідовними між машинами?

Тримайте baseline settings.json (або фрагмент) під версійним контролем і застосовуйте його на всіх машинах. Уникайте перетворення навігації та безпеки на «локальне як заманеться».

9) Чи викликає GPU-прискорення проблеми?

Зазвичай воно допомагає. Коли шкодить — це проявляється як графічні артефакти з певними шрифтами або в віддалених сесіях. Спочатку доведіть, що шелл швидкий; потім тестуйте з простішим шрифтом і меншими візуальними ефектами.

Наступні кроки, які ви реально зробите

  1. Створіть мінімальний on-call профіль (PowerShell 7 з -NoProfile або полегшений скрипт профілю). Зробіть його дефолтним для роботи з інцидентами.
  2. Перейменуйте і зафіксуйте профілі, щоб ніколи не плутати PS5 vs PS7 або staging vs prod знову.
  3. Оберіть один шрифт, перевірте, що він встановлений, і перестаньте ганятися за гліфовими драконами, якщо вони вам справді не потрібні.
  4. Стандартизувати 6–10 скорочень і практикувати їх, поки вони не стануть автоматичними. У стресі руки мають знати маршрут.
  5. Запустіть план швидкої діагностики наступного разу, коли Terminal «здаватиметься повільним». Спочатку вимірюйте. Потім виправляйте реальне вузьке місце.

Якщо ви зробите лише одне: зробіть prod візуально гучним, а on-call профіль — нудним. Це професіоналізм, замаскований під естетику.

← Попередня
Зовнішній монітор не виявляється: єдиний драйвер, який вам бракує
Наступна →
BIND9: Конфігурація, що виглядає правильно, але спричиняє періодичні NXDOMAIN

Залишити коментар