Тяжкое наследие прошлого. Проблемы командной строки Windows

https://blogs.msdn.microsoft.com/commandline/2018/06/20/windows-command-line-backgrounder/
  • Перевод
Предисловие от автора, Рича Тёрнера из Microsoft. Это статья о командной строке: от её появления и эволюции до планов капитального ремонта Windows Console и командной строки в будущих версиях Windows. Будь вы опытным профессионалом или новичком в IT, надеемся, что вы найдёте статью интересной.

Давным-давно в далёкой-далёкой серверной...


С первых дней развития информатики людям нужен был эффективный способ передавать компьютеру команды и данные и видеть результат выполнения этих команд/вычислений.

Одним из первых по-настоящему эффективных человеко-машинных интерфейсов стал Tele-Typewriter или «телетайп». Это электромеханическая машина с клавиатурой для ввода данных и каким-нибудь устройством вывода — сначала использовался принтер, позже экран.

Вводимые оператором символы локально буферизуются и отправляются с телетайпа на соседний компьютер или мейнфрейм в виде серии сигналов по электрическому кабелю (например, RS-232) со скоростью 10 символов в секунду (110 бод, бит в секунду, bps):


Телетайп Model 33 ASR

Примечание: Дэвид Гессвейн ведёт отличный сайт по PDP-8, где можно найти больше информации об ASR33 (и соответствующей технологии PDP-8), в том числе фотографии, видео и др.

Программа на компьютере получает введённые символы, решает, что с ними делать, и, возможно, асинхронно отправляет ответ на телетайп. Телетайп может напечатать/показать оператору полученные символы.

Затем технология улучшилась, скорость передачи выросла до 19200 bps, а шумные и дорогие принтеры заменили ЭЛТ-дисплеями (широко распространённый тип дисплеев в 80-е и 90-е годы), как на популярном терминале DEC VT100:


Терминал DEC VT100

Хотя технология улучшилась, но эта модель — терминал отправляет символы программе на компьютере, а он выдаёт текст для пользователя — осталась и сегодня как фундаментальная модель взаимодействия всех командных строк и консолей на всех платформах!


Архитектура терминала и командной строки

Модель по-своему элегантна. Одна из причин — в сохранении простоты и цельности каждого компонента: клавиатура выдаёт символы которые буферизуются как электрические сигналы. Устройство вывода просто выдаёт на дисплей (бумагу/экран) символы, полученные с компьютера.

На каждом этапе в системе передаётся только поток символов, так что это относительно простой процесс для внедрения различной инфраструктуры связи. Например, для добавления модемов, чтобы передавать потоки входных и выходных символов на большие расстояния по телефонным линиям.

Кодировка текста


Важно помнить, что терминалы и компьютеры обмениваются данными через потоки символов. При нажатии клавиши на клавиатуре терминала на подключенный компьютер отправляется значение, представляющее введённый символ. Нажмите клавишу ’A’ — и отправляется значение 65 (0x41). Нажмите ’Z’ — и отправляется 90 (0x5a).

7-битная кодировка ASCII


Список символов и их значений определён в стандарте American Standard Code for Information Interchange (ASCII), он же стандарт ISO/IEC 646 / ECMA-6 — «7-битный кодированный набор символов», который определяет:

  • 128 значений, представляющих печатные латинские символы A−Z (65-90), a−z (97−122), 0−9 (48−57)
  • Много общих знаков препинания
  • Несколько непечатаемых управляющих кодов (0−31 и 127):


Стандартные символы 7-битной ASCII

Когда 7 бит недостаточно: кодовые страницы


Однако 7 бит не обеспечивают достаточно места для кодирования многих диакритических знаков, знаков препинания и символов, используемых в других языках и регионах. Так что с добавлением дополнительного бита можно расширить таблицу символов ASCII дополнительными наборами «кодовых страниц» для символов 128−255 (и возможного переопределения нескольких непечатаемых символов ASCII).

Например, IBM ввела кодовую страницу 437 с несколькими графическими символами вроде ╫ (215) и ╣(185) и математическими, включая π (227) и ± (241), а также переопределила печатные символы для обычно непечатаемых символов 1−31:


Кодовая страница 437

Кодовая страница Latin-1 определяет множество символов, используемых языками на основе латиницы:


Кодовая страница Latin-1

Во многих окружениях командной строки и оболочках можно изменять текущую кодовую страницу, чтобы терминал отображал различные символы (в зависимости от доступных шрифтов), особенно для символов со значением 128−255. Но неправильно указанная кодовая страница приведёт к отображению кракозябр. И да, «кракозябры» — это настоящий термин! Кто бы мог подумать? ;)

Когда 8 бит недостаточно: Юникод


Кодовые страницы временно решили проблему, но у них много недостатков, например, они не позволяют отображать текст одновременно из нескольких кодовых страниц/языков. Таким образом, пришлось ввести новую кодировку, которая точно отображает каждый символ и алфавит для всех языков, известных человечеству, оставляя ещё много свободного места! Представляем Юникод.

Юникод — это международный стандарт (ISO/IEC 10646), который в данный момент определяет 137 439 символов из 146 современных и исторических письменностей, а также многие символы и глифы, в том числе многочисленные смайлики, которые широко используются практически в каждом приложении, платформе и устройстве. Юникод регулярно обновляется дополнительными системами письменности, новыми/исправленными смайликами, символами и т. д.

Юникод также определяет «непечатаемые» символы форматирования, которые позволяют, например, соединить символы и/или повлиять на предыдущие или последующие символы! Это особенно полезно в письменностях вроде арабской, где лигатура конкретного символа определяется окружающими. Эмодзи могут использовать соединительный символ нулевой ширины (zero width joiner), чтобы объединить несколько символов в один визуальный глиф. Например, эмодзи кота-ниндзя Microsoft формируются путём соединения кота с другими эмодзи:


Эмодзи кота-ниндзя Microsoft

Когда байтов слишком много: UTF-8!


Для уникального и систематического представления всех символов требуется большое пространство, до нескольких байт на каждый символ.

Поэтому для экономии было разработано несколько новых кодировок Юникода. Среди самых популярных — UTF-32 (4 байта на символ), UTF-16/UCS-2 (2 байта) и UTF-8 (1−4 байта на символ).

Во многом благодаря обратной совместимости с ASCII и экономии места UTF-8 стала самой популярной кодировкой Юникода в интернете. Она демонстрирует взрывной рост с 2008 года, когда обогнала по популярности ASCII и другие популярные кодировки:


Рост популярности кодировки UTF-8 (источник: Википедия)

Таким образом, поначалу терминалы поддерживали 7-битный, а затем 8-битный текст ANSI, но большинство современных терминалов поддерживают текст Unicode/UTF-8.

Итак, что такое командная строка и что такое оболочка?


«Командная строка» или CLI (интерфейс/интерпретатор командной строки) описывает самый фундаментальный механизм, через который человек управляет компьютером: CLI принимает введённый оператором ввод и выполняет требуемые команды.

Например, echo Hello отправляет текст «Hello» на устройство вывода (например, на экран). dir (Cmd) или ls (PowerShell/*NIX) перечисляет содержимое текущего каталога и т.д.

Раньше доступные команды были относительно простыми, но операторы требовали всё более изощрённых команд и возможности писать скрипты для автоматизации повторяющихся или сложных задач. Таким образом, процессоры командной строки стали сложнее и превратились в то, что теперь называют «оболочкой» командной строки (shell).

В Unix/Linux оригинальная оболочка Unix (sh) породила множество оболочек, включая Korn shell (ksh), C shell (csh) и Bourne Shell (sh). В свою очередь, на их основе создан Bourne Again Shell (bash) и т.д.

В мире Microsoft:

  • Оригинальный MS-DOS (command.com) был относительно простой оболочкой командной строки
  • «Командная строка» Windows NT (cmd.exe) разработана с учётом совместимым с устаревшими скриптами command.com, плюс добавлены несколько команд для новой, более мощной операционной системы
  • В 2006 году Microsoft выпустила Windows PowerShell
    • PowerShell — это современная объектная оболочка командной строки, которая позаимствовала функции других оболочек и включает в себя возможности .NET CLR и фреймворка .NET
    • С помощью PowerShell можно писать скрипты и автоматизировать практически все аспекты одного или нескольких компьютеров под Windows, сети, систем хранения данных, БД и т.д.
    • В 2017 году Microsoft открыла исходный код PowerShell, разрешив запуск на macOS, разных вариантах Linux и BSD
  • В 2016 году Microsoft представила подсистему Windows для Linux (WSL)
    • Позволяет запускать обычные немодифицированные двоичные файлы Linux непосредственно в Windows 10
    • Пользователи устанавливают один или несколько обычных дистрибутивов Linux из магазина Windows
    • Можно запустить один или несколько экземпляров дистрибутива параллельно с другими, а также параллельно с существующими приложениями и средствами Windows
    • WSL позволяет запускать бок о бок все инструменты Windows и инструменты командной строки Linux без использования ресурсоёмких виртуальных машин

Мы ещё вернёмся к оболочкам командной строки Windows, но пока запомним, что существуют разные оболочки, они принимают команды, введённые пользователем/оператором, и выполняют широкий спектр задач по мере необходимости.

Современная командная строка


Современные компьютеры значительно мощнее «тупых терминалов» прошлого и обычно работают под управлением десктопной ОС (например, Windows, Linux, macOS) с графическим пользовательским интерфейсом (GUI). Такое окружение GUI позволяет нескольким приложениям работать одновременно в отдельных окнах на экране и/или невидимо в фоновом режиме.


Cmd, PowerShell и Ubuntu Linux под WSL работают на независимых инстансах консоли

На смену громоздким, неповоротливым электромеханическим телетайпам пришли современные консольные/терминальные приложения, которые работают в окошке на экране компьютера, но по-прежнему выполняют такие же необходимые функции, как аппаратные терминалы из прошлого.

Аналогично и приложения командной строки, к которым подключены терминалы, работают как и раньше: получают входные символы, решают, что делать с этими символами, (необязательно) выполняют работу — и могут выдать текст для отображения пользователю. Только вместо связи по медленным каналам TTY терминальные приложения и приложения командной строки на одной машине общаются по очень скоростным каналам Pseudo Teletype (PTY) в памяти.


Современная командная строка

Современные терминалы в основном взаимодействуют с приложениями командной строки, запущенными локально. Но конечно, они также могут взаимодействовать с приложениями командной строки, запущенными на других машинах в той же сети или даже с удалёнными машинами на другой стороне света через интернет. Это «удалённое» взаимодействие с командной строкой — мощный инструмент, который популярен на каждой платформе, особенно на *NIX.

Эволюция командной строки


Скромное начало: MS-DOS


На заре компьютерной индустрии управление большинством компьютеров осуществлялось путём ввода команд в командной строке. За рыночную долю боролись компьютеры под Unix, CP/M, DR-DOS и других. В итоге система MS-DOS стала стандартом де-факто для IBM PC и всех совместимых компьютеров:


MS-DOS 6.0

Как и большинство основных операционных систем того времени, интерпретатор командной строки или «оболочка» в MS-DOS предоставляла простой, но относительно эффективный набор команд и синтаксис командных скриптов для написания batch-файлов (.bat).

Предприятия крупного и малого бизнеса очень быстро взяли на вооружение MS-DOS и в совокупности создали многие миллионы скриптов, некоторые из которых всё ещё используются сегодня! Batch-скрипты применяются для автоматизации настройки ПК, установки/изменения параметров безопасности, обновления программного обеспечения, сборки кода и т.д.

Вы редко или никогда не увидите реальную работу такого скрипта, потому что многие из них выполняются в фоновом режиме, например, при авторизации на компьютере. Но сотни миллиардов скриптов командной строки и команд выполняются каждый день только на Windows!

Командная строка представляет мощный инструмент в руках человека, который имеет терпение и упорство, чтобы научиться выжимать максимум из доступных команд и инструментов. Но большинству обычных пользователей сложно эффективно управлять компьютером из командной строки. Большинству не нравилось, что нужно изучать и запоминать много словно мистических аббревиатур, чтобы компьютер произвёл хоть какое-нибудь полезное действие.

Требуется более удобный и ориентированный на производительность пользовательский интерфейс.

Графический интерфейс идёт в мейнстрим


Добро пожаловать в графический интерфейс пользователя (GUI), изобретённый в Xerox Alto.

Вскоре после изобретения появилось много конкурирующих GUI на компьютерах Lisa и Macintosh от Apple, Commodore Amiga (Workbench), Atari ST (DRI GEM), Acorn Archimedes (Arthur/RISC OS), Sun Workstation, X11/X Windows и многих других, в том числе Microsoft Windows.

Windows 1.0 вышла в 1985 году и являлась по сути приложением MS-DOS, которое предоставляло простое окружение GUI с плиточным окном, позволяя пользователям запускать несколько приложений бок о бок:


Windows 1.01 на MS-DOS

Windows 2.x, 3.x, 95 и 98 работали на базе MS-DOS. Более поздние версии Windows начали заменять некоторые функции MS-DOS альтернативами Windows (например, операции с файловой системой), но все они полагались на фундамент MS-DOS.

Примечание: Windows ME (Millennium Edition) стала интересным гибридом. В ней наконец-то заменили поддержку MS-DOS и поддержку реального режима из предыдущих версий Windows несколькими новыми функциями (особенно технологии Gaming & Media). Некоторые функции позаимствованы из Windows 2000 (например, новый стек TCP/IP), но настроены для работы на домашних ПК, которым трудно запустить полноценную NT.

Но Microsoft понимала, что не может бесконечно растягивать архитектуру и возможности MS-DOS и Windows. Требовалась новая операционная система с прицелом на будущее.

Microsoft — лидер рынка Unix! Да, серьёзно!


Разрабатывая MS-DOS, Microsoft также занималась поставкой Xenix — фирменного порта Unix версии 7 — для различных процессорных и машинных архитектур, включая Z8000, 8086/80286 и 68000.

К 1984 году Xenix от Microsoft стал самым популярным вариантом Unix в мире!

Тем временем распад Bell Labs — родины Unix — привёл к появлению AT&T, которая начала продавать Unix System V производителям компьютеров и конечным пользователям.

Microsoft понимала, что отсутствие собственной ОС ставит под угрозу её способности для развития. Поэтому было принято решение отказаться от Xenix: в 1987 году Microsoft передала Xenix своему партнёру Santa Cruz Operation (SCO), с которым работала над несколькими проектами по портированию и улучшению Xenix на различных платформах.

Microsoft + IBM == OS/2… ненадолго


В 1985 году Microsoft начала работать с IBM над новой операционной системой OS/2. Она изначально планировалась как «более функциональная DOS» для некоторых современных 32-битных CPU и с учётом других технологий, которые быстро порождались в IBM и у других OEM.

Но история OS/2 оказалась слишком бурной. В 1990 году Microsoft и IBM прекратили сотрудничество. Это было обусловлено рядом факторов, в том числе значительными культурными различиями между разработчиками IBM и Microsoft, проблемами планирования, а также взрывным успехом и ростом внедрения Windows 3.1. IBM продолжала разработку и поддержку OS/2 до конца 2006 года.

К 1988 году Microsoft убедилась, что будущий успех требует более масштабного, смелого и амбициозного подхода. Такой подход потребует новой, современной операционной системы, которая будет поддерживать амбициозные цели компании.

Большая ставка Microsoft: Windows NT


В 1988 году Microsoft пригласила Дэйва Катлера, создателя популярной и уважаемой операционной системы VAX/VMS в компании DEC. Его задача — создать новую, современную, независимую от платформы операционную систему, которой Microsoft будет владеть, контролировать и на которой во многом построит своё будущее.

Этой новой операционной системой стала Windows NT: фундамент, на котором построены Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8 и Windows 10, а также во все версии Windows Server, Windows Phone 7+, Xbox и HoloLens!

Windows NT изначально спроектирована как кроссплатформенная система. Сначала она поддерживала Intel i860, затем MIPS R3000, Intel 80386+, DEC Alpha и PowerPC. С тех пор семейство ОС Windows NT портировали для поддержки процессорных архитектур IA64 Itanium, x64 и ARM/ARM64, среди прочих.

Windows NT предоставляет интерфейс командной строки через терминальное приложение Windows Console и командную строку Command Prompt (cmd.exe). Cmd разработан на максимальную совместимость с пакетными скриптами MS-DOS, чтобы помочь бизнесу перейти на новую платформу.

Мощь PowerShell


Cmd сохраняется в Windows по сей день (и, вероятно, сохранится в течение многих десятилетий). Поскольку его основная задача — обеспечить максимальную обратную совместимость, Cmd редко улучшается. Даже «исправление ошибок» зачастую затруднено, если эти «баги» существовали в MS-DOS или более ранних версиях Windows!

В начале 2000-х оболочка Cmd уже устарела: Microsoft и её клиенты срочно нуждались в более мощной и гибкой командной строке. Из этой потребности появился PowerShell (который возник из «Манифеста Монады» Джеффри Сновера).

PowerShell — это объектно-ориентированная оболочка, в отличие от оболочек на основе файлов/потоков, которые принято использовать в мире *NIX: вместо потоков текста PowerShell обрабатывает потоки объектов. Он предоставляет авторам скриптов возможность прямого доступа и манипуляций с объектами и их свойствами вместо написания множества скриптов для анализа и обработки текста (как sed/grep/awk/lex/др.).

Созданные на базе .NET Framework и среды Common Language Runtime (CLR), язык и синтаксис PowerShell разработаны для объединения богатства экосистемы .NET со многими распространёнными и полезными функциями из множества других языков сценариев оболочки с акцентом на то, чтобы скрипты обеспечивали максимальную консистентность и исключительную… ну… мощь. :)

Чтобы узнать больше о PowerShell, рекомендую прочитать книгу «PowerShell в действии» (Manning Press), написанную Брюсом Пайеттом — разработчиком синтаксиса и языка PowerShell. В частности, первые несколько глав содержат подробное обоснование структуры языка.

PowerShell был принят для использования многими технологиями на платформе Microsoft, включая Windows, Exchange Server, SQL Server, Azure и многими другими. Он предоставляет очень согласованные команды для администрирования и управления практически всеми аспектами Windows и/или среды.

PowerShell Core — это PowerShell с открытым исходным кодом, доступное для Windows и различных версий Linux, BSD и macOS.

POSIX для NT, Interix и служб UNIX


При проектировании NT компания команда Катлера специально разработала ядро NT и операционную систему для поддержки нескольких подсистем-интерфейсов между кодом пользовательского режима и основным ядром.

Когда в 1993 году вышла первая Windows NT версии 3.1, она поддерживала несколько подсистем: МЅ-DOS, Windows, OS/2 и POSIX v1.2. Эти подсистемы позволяли на одной машине и базовой ОС запускать приложения, нацеленные на несколько платформ операционной системы без виртуализации или эмуляции — это внушительная разработка даже по меркам сегодняшнего дня!

Оригинальная реализация POSIX в Windows NT была приемлемой, но для неё требовались значительных улучшения. Поэтому Microsoft приобрела Softway Systems и её POSIX-совместимую подсистему Interix для NT. Изначально Interix поставлялась как отдельное дополнение, а затем её объединили с несколькими полезными утилитами и инструментами и выпустили в виде Services For Unix (SFU) в Windows Server 2003 R2 и Windows Vista. Однако поддержку SFU пришлось прекратить после Windows 8, в основном, из-за недостаточной популярности.

А потом произошла забавная вещь…

Windows 10 — новая эра для командной строки Windows!


В начале разработки Windows 10 компания открыла страницу UserVoice с вопросом, какие функции люди хотят реализовать в различных областях ОС. Сообщество разработчиков особенно громко требовало от Microsoft две вещи:

  1. Внести значительные улучшения в консоль Windows
  2. Предоставить пользователям возможность запускать средства Linux в Windows

На основе этих отзывов Microsoft сформировала две новые группы:

  1. Группа разработки Windows Console и командной строки, которой поручили провести капитальный ремонт инфраструктуры Windows Console и командной строки
  2. Группа разработки Windows Subsystem for Linux (WSL)

Остальное, как говорится, история!

Подсистема Windows для Linux (WSL)


Основанные на GNU/Linux «дистрибутивы» (сочетания ядра Linux и коллекций инструментов пользовательского режима) становятся всё популярнее, особенно на серверах и в облаке. Хотя в Windows имелась POSIX-совместимая среда выполнения, но SFU не мог запускать многие инструменты и двоичные файлы Linux из-за дополнительных системных вызовов и различий в поведении по сравнению с традиционной Unix/POSIX.

После анализа обратной связи от разработчиков и технически подкованных пользователей Windows, а также в связи с растущим спросом внутри самой Microsoft, компания изучила несколько вариантов, и в конечном итоге решила позволить на Windows запуск оригинальных немодифицированных бинарных файлов Linux!

В середине 2014 года Microsoft сформировала группу разработки того, что станет подсистемой Windows для Linux (WSL). WSL впервые анонсировали в сборке Build 2016, а вскоре предварительная версия вышла на канале Windows 10 Insider.

С тех пор WSL обновляется в большинстве инсайдерских сборок и в каждом крупном выпуске ОС с момента Anniversary Update осенью 2016 года. В каждой новой версии увеличивается функциональность, совместимость и стабильность WSL: в первой версии это был интересный эксперимент, который мог запускать лишь несколько распространённых программ Linux. При активной помощи сообщества (всем спасибо!) разработчики быстро дорабатывали WSL, так что вскоре она получила много новых возможностей и научилась запускать всё более сложные бинарники Linux.

Сегодня (середина 2018 года) WSL запускает большинство двоичных файлов Linux, программы, компиляторы, компоновщики, отладчикии т.д. Многие разработчики, IT-специалисты, инженеры DevOps и многие другие, кому необходимо запускать или создавать инструменты, приложения, службы Linux и т. д., получили резкое повышение производительности и возможность запускать свои любимые инструменты Linux вместе с любимыми инструментами для Windows на одном компьютере, без загрузки двух операционных систем.

Команда WSL продолжает улучшать WSL в части выполнения задач Linux, повышения производительности и интеграции с Windows.

Перезагрузка и капитальный ремонт Windows Console


В конце 2014 года проект по созданию подсистемы Windows для Linux (WSL) шёл полным ходом, и на фоне взрыва оживлённого интереса пользователей к командной строке стало очевидно, что консоль Windows явно нуждается в некотором апгрейде.

В частности, консоли не хватало многих функций, привычных для современных *NIX-совместимых систем, таких как возможность парсинга и вывода последовательностей ANSI/VT, широко используемых в мире *NIX для вывода насыщенного и подсвеченного текста и текстовых UI.

В чём тогда смысл разработки WSL, если пользователь не сможет корректно использовать инструменты Linux?

Ниже пример того, что отображает консоль Windows 7 и Windows 10: обратите внимание, что Windows 7 (слева) не в состоянии правильно отобразить VT, сгенерированный линуксовыми программами tmux, htop, Midnight Commander и cowsay, но они корректно выглядят в Windows 10 (справа):


Сравнение консоли Windows 7 и Windows 10

Так, в 2014 году была сформирована небольшая «группа Windows Console». На неё возложили задачу распутать, понять и улучшить кодовую базу Windows Console… которой к этому времени было около 28 лет — больше, чем программистам, которые работают над этим проектом.

Как подтвердит любой разработчик, которому когда-либо приходилось брать старый, грязный, плохо поддерживаемый код, улучшение такого кода представляет собой сложную задачу. Ещё сложнее не нарушить существующее поведение. Для обновления самой часто запускаемой программы в Windows, не нарушив работу миллионов клиентских скриптов, инструментов, скриптов авторизации, систем сборки, производственных систем, систем анализа и прочих, требуется немало «внимания и терпения». ;)

Для разработчиков проблема усугубилась, когда они поняли всю строгость требований к консоли со стороны клиентов. Например, если производительность консоли изменялась на 1−2% от сборки к сборке, то срабатывали сигналы тревоги в группе Windows Build, что приводило… гм… к «быстрой и прямой обратной связи», то есть требованию немедленного исправления.

Итак, когда мы будем обсуждать улучшения консоли и новые функции, помните, что есть несколько незыблемых принципов, которым должно соответствовать каждое изменение, в том числе:

  1. НЕ допускать новых уязвимостей
  2. НЕ ломать инструменты, скрипты, команды и т. д. у существующих клиентов (внутренних или внешних)
  3. НЕ снижать производительность и не увеличивать потребление памяти/IO (без чётких и хорошо доведённых причин)

За последние три года команда Windows Console провела следующую работу:

  • Капитальный ремонт внутренних компонентов
    • Значительное упрощение и уменьшение кодовой базы
    • Замена нескольких внутренних коллекций, списков, стеков и т.д. контейнерами STL
    • Разбиение на модули и изоляция логических и функциональных единиц кода, что позволяет улучшать функции (а иногда и заменять их), не «ломая мир»
  • Объединение нескольких ранее отдельных и несовместимых консольных движков в один
  • МНОЖЕСТВО улучшений безопасности и надёжности
  • Возможность парсинга и вывода последовательностей ANSI/VT, что позволяет консоли точно отображать насыщенный текстовый вывод из *NIX и других современных инструментов командной строки и приложений
  • Поддержка 24-битного цвета вместо прежних 16 цветов!
  • Улучшенная безбарьерность: Narrator и другие приложения безбарьерной среды работают в окне консоли
  • Добавлена/улучшена поддержка мыши и сенсорного ввода

И работа продолжается! В настоящее время мы завершаем реализацию нескольких захватывающих новых функций.

К чему был этот урок истории?

Я надеюсь, вы поняли, что командная строка остаётся ключевым компонентом стратегии, платформы и экосистемы Microsoft.

Хотя для конечных пользователей Microsoft продвигала графический интерфейс, сама компания и её технические клиенты/пользователи/партнёры в значительной степени полагались на командную строку для выполнения множества технических задач.

На самом деле Microsoft буквально не смогла бы создать ни Windows, ни любой другой из своих программных продуктов без быстрой, эффективной, стабильной и безопасной консоли!

На протяжении эпох MS-DOS, Unix, OS/2 и Windows командная строка оставалась, пожалуй, самым важным инструментом в наборе инструментов каждого технического пользователя. Даже многие пользователи, которые никогда не вводили команды в окно, в реальности используют консоль каждый день! Даже сборка кода в Visual Studio (VS) происходит в скрытом окне консоли. При использовании Exchange Server или средств администрирования SQL Server многие из этих команд выполняются с помощью PowerShell в скрытой консоли.

Механика Windows Console


Во время начала разработки Windows NT в 1989 году не было ни графического интерфейса, ни рабочего стола. Была только полноэкранная командная строка, которая визуально напоминала MS-DOS. Когда появилась реализация графического интерфейса Windows, потребовалось создать приложение консоли для GUI — и таким образом родилась Windows Console! Это одно из первых приложений Windows NT с графическим интерфейсом и, безусловно, одно из старейших приложений Windows, которое по-прежнему используется повсеместно!

Кодовой базе консоли Windows в настоящее время (июль 2018 года) почти 30 лет… по сути, больше, чем разработчикам, которые сейчас над ней работают!

Что делает консоль?


Как мы узнали ранее, у терминала относительно простой алгоритм работы:

  • Обработать пользовательский ввод
    • Принять входной сигнал от приборов, включая клавиатуру, мышь, тачскрин и др.
    • Перевести ввод в соответствующие символы и/или последовательности ANSI/VT
    • Отправить символы в подключенное приложение/инструмент/оболочку
  • Обработать вывод приложения:
    • Принять вывод текста из покдлюченного приложения/инструмента командной строки
    • Обновлять экран по мере необходимости, основываясь на полученных данных от приложения (например, полученный текст, перемещения курсора, изменение цвета текста и т.д.)
  • Обработать системные взаимодействия:
    • Запуск по запросу
    • Управление ресурсами
    • Изменение размера/развернуть окно/свернуть окно и т.д.
    • Завершение по запросу или после закрытия канала связи

Но консоль Windows работает немного иначе:

Механика Windows Console


Консоль Windows — обычный исполняемый файл Win32. Изначально он написан на C, но большая часть кода сейчас переносится на C++ по мере того, как разработчики модернизируют и разбивают на модули кодовую базу.

Если вам интересны такие вещи: многие спрашивали, Windows написана на C или C++. Ответ такой: несмотря на объектно-ориентированный дизайн NT, как и большинство ОС, Windows почти полностью написана на C! Почему? Потому что C++ увеличивает потребление памяти и привносит накладные расходы на выполнение кода. Даже сегодня скрытые затраты на выполнение кода C++ могут удивить, но ещё в 1990-х, когда память стоила около $60/МБ (да… $60 за МЕГАБАЙТ!), скрытые затраты на vtables и прочее были значительными. Кроме того, затраты на косвенное обращение к виртуальным методам и разыменование объектов в то время могли привести к очень значительным потерям производительности и масштабированию кода C++. В наше время нужно соблюдать осторожность, но издержки производительности C++ на современных компьютерах вызывают намного меньше беспокойства. Часто это приемлемый компромисс, учитывая безопасность, читабельность и лучшую сопровождаемость кода… именно поэтому мы постепенно переписываем код консоли на современном C++!

Так что внутри консоли Windows?


До Windows 7 инстансы консоли Windows размещались в критически важной подсистеме Client Server Runtime Subsystem (CSRSS)! Но в Windows 7 из соображений безопасности и надёжности консоль переместили из CSRSS в следующие бинарники:

  • conhost.exe — пользовательский режим консоли Windows UX и механика командной строки
  • condrv.sys — драйвер ядра Windows, обеспечивающий коммуникации между conhost и одной или несколькими оболочками командной строки/инструментами/приложениями

Высокоуровневая схема текущей внутренней архитектуры консоли выглядит следующим образом:



Ядро консоли состоит из следующих компонентов (снизу вверх):

  • ConDrv.sys — драйвер режима ядра
    • Обеспечивает высокопроизводительный канал связи между консолью и любыми подключенными приложениями командной строки
    • Переносит туда и обратно сообщения IO Control (IOCTL) между приложениями командной строки и консолью, к которой они «прикреплены»
    • Консольные сообщения IOCTL содержат:
      • Данные, представляющие запросы на выполнение вызовов API для экземпляра консоли
      • Текст, отправляемый из консоли в приложение командной строки
  • ConHost.exe — приложение Win32 GUI:
    • ConHost Core — внутренности и механика
      • Сервер API: преобразует сообщения IOCTL, полученные из приложений командной строки, в вызовы API и отправляет текстовые записи из консоли в приложение командной строки
      • API: реализует консольный API Win32 и логику для всех операций, которые консоль может попросить выполнить
      • Буфер ввода: хранит записи событий клавиатуры и мыши, генерируемые пользовательским вводом
      • VT Parser: если включен, анализирует последовательности VT, извлекает их из текста и генерирует эквивалентные вызовы API
      • Буфер вывода: хранит текст, отображаемый на дисплее консоли. По сути, это 2D-массив структур CHAR_INFO, которые содержат символьные данные и атрибуты каждой ячейки (подробнее о буфере ниже)
      • Другое: в схему не включены инфраструктура сохранения/извлечения значений из реестра и/или файлов ярлыков и т.д.
    • Console UX App Services — слой UX и UI
      • Управляет макетом, размером, положением и прочими характеристиками окна консоли на экране
      • Отображает и обрабатывает параметры UI и т.д.
      • Прокачивает очередь сообщений Windows, обрабатывает их и преобразует введённые пользователем данные в записи событий клавиш и мыши, сохраняя их во входном буфере

Windows Console API


Как видно из схемы архитектуры, в отличие от терминалов NIX, консоль отправляет/получает вызовы API и/или данные в виде сообщений IO Control (IOCTL), а не текста! Даже встроенные в текст последовательности ANSI/VT из приложений командной строки (в основном Linux), извлекаются, анализируются и преобразуются в вызовы API!

Это различие раскрывает ключевое фундаментальное философское различие между *NIX и Windows: в *NIX «всё является файлом», а в Windows «всё является объектом»!

У обоих подходов есть преимущества и недостатки, которые мы перечислим, но не будем подробно обсуждать. Просто помните, что это ключевое различие в философии объясняет многие фундаментальные различия Windows и *NIX!

В *NIX всё является файлом


Когда Unix впервые появился в конце 1960-х и начале 1970-х годов, одним из основных принципов стало то, что (где это возможно) всё следует абстрагировать как файловый поток. Одна из ключевых целей заключалась в упрощении кода для доступа к устройствам и периферии: если все устройства представляются в ОС как файлы, то коду легче получить к ним доступ.

Эта философия работает на самом глубоком уровне: можно даже перемещаться и опрашивать большую часть конфигурации ОС и компьютера под *NIX, перемещаясь по псевдо/виртуальным файловым системам, которые показывают то, что кажется «файлами» и папками, но на самом деле представляет собой конфигурацию машины и оборудование.

Например, в Linux можно исследовать свойства процессоров, изучая содержимое псевдофайла /proc/cpuinfo:



Но простота и согласованность этой модели могут дорого стоить: извлечение/анализ конкретной информации в псевдофайлах часто требует специальных инструментов, таких как sed, awk, perl, python и т.д. Эти инструменты используются для написания команд и скриптов парсинга текстового содержимого, поиска определённых шаблонов, полей и значений. Некоторые из скриптов могут быть довольно сложными, часто трудными в обслуживании и хрупкими — если структура, шаблон и/или формат текста изменятся, многие скрипты, вероятно, потребуется обновить.

В Windows всё является объектом


Когда проектировалась Windows NT, «объекты» рассматривались как будущее в разработке программного обеспечения: «объектно-ориентированные» языки программирования появлялись быстрее, чем тараканы: Simula и Smalltalk уже зарекомендовали себя, а C++ набирал популярность. За ними последовали другие объектно-ориентированные языки, в том числе Python, Eiffel, Objective-C, ObjectPascal/Delphi, Java, C# и многие другие.

Результат предсказуем. Созданная в те пьянящие, объектно-ориентированные дни (около 1989 года) Windows NT разработана с философией, что «всё является объектом». На самом деле одной из самых важных частей ядра NT является Менеджер объектов!

Windows NT предоставляет богатый набор Win32 API для получения и/или управления объектами ОС. Разработчики используют Win32 API для сбора и представления информации, похожей на данные из псевдофайлов и инструментов *NIX, только через объекты и структуры. А поскольку парсеры, компиляторы и анализаторы понимают структуру объектов, то многие ошибки кодирования часто проявляются на ранней стадии, что помогает проверить синтаксическую и логическую правильность намерений программиста. Со временем это может привести к уменьшению сбоев, волатильности и лучшему порядку.

Итак, возвращаясь к основной дискуссии о консоли Windows: команда NT решила построить «консоль», отличную от традиционного терминала *NIX в нескольких ключевых областях:

  • Console API: вместо того, чтобы полагаться на способность программистов генерировать корректные ANSI/VT-последовательности, которые трудно проверить, консоль Windows управляется через богатые консольные API
  • Общие службы: чтобы избежать дублирования служб во всех оболочках командной строки (например, журнал команд, псевдонимы команд), консоль сама предоставляет некоторые из них через Console API

Проблемы с консолью Windows


Хотя консольные API стали очень популярны в инструментах и сервисах командной строки, но ориентированная на API модель имеет определённые недостатки, перечисленные ниже.

Только для Windows


Многие средства командной строки и приложения широко используют Console API.

В чём проблема? Они работают только под Windows.

Таким образом, в сочетании с другими различиями (например, в жизненном цикле и т.д.), приложения командной строки Windows не всегда легко переносятся под *NIX и наоборот.

Из-за этого в экосистеме Windows распространены свои собственные, часто похожие, но обычно отличающиеся средства командной строки и приложения. Это означает, что при использовании Windows пользователям приходится изучать один набор приложений и инструментов командной строки, оболочек, языков сценариев и т.д., а при использовании *NIX — другой набор.

У этой проблемы нет простого решения: консоль Windows и командную строку нельзя просто выбросить и заменить на bash и iTerm2 — существуют сотни миллионов приложений и сценариев, которые зависят от консоли Windows и оболочек Cmd/PowerShell.

Сторонние инструменты, такие как Cygwin, отлично переносят многие основные инструменты GNU и библиотеки совместимости в Windows, но не могут запускать непортированные, неизменённые бинарники Linux. Это очень важно, так как многие пакеты и модули Ruby, Python, Node зависят от бинарных файлов Linux и/или зависят от поведения *NIX.

Эти причины привели к тому, что Microsoft расширила совместимость с Windows, разрешив запуск аутентичных двоичных файлов и средств Linux в подсистеме Windows для Linux (WSL). С помощью WSL пользователи теперь могут загружать и устанавливать один или несколько дистрибутивов Linux бок о бок на одной машине, а также использовать apt/zypper/npm/gem/др. для установки и запуска подавляющего большинства инструментов командной строки Linux вместе с их любимыми приложениями и инструментами Windows.

Тем не менее, у нативной консоли остаётся функциональность, которая отсутствует в сторонних терминалах: в частности, Windows Console предоставляет сервисы command-history и command-alias, чтобы каждой оболочке (в частности) не пришлось повторно реализовать одинаковую функциональность.

Сложности с удалённой работой


Как говорилось в начале статьи, терминалы изначально были отделены от компьютера, к которому подключены. Сегодня эта конструкция сохраняется: большинство современных терминалов и оболочек/приложений/проч. командной строки изолированы в рамках отдельных процессов и/или машин.

На *NIX-платформах парадигма изолированности терминалов и приложений командной строки с простым обменом символами привела к тому, что там легко получить доступ и работать с удалённого компьютера/устройства. Если терминал и приложение командной строки обмениваются потоками символов по какой-то упорядоченной инфруструктуре (TTY, PTY и т.д.), то очень легко работать удалённо.

Но в Windows многие приложения командной строки зависят от вызова API консоли и предполагают выполнение на той же машине, что и сама консоль. Это затрудняет удалённое управление. Как приложению командной строки удалённо обратиться к API на консоли локального компьютера? Хуже того, как удалённое приложение обратится к Console API, если доступ к нему осуществляется через терминал на Mac или Linux?!

Извините, что дразню вас, но более подробно мы вернёмся к этой теме в следующей статье.

Запуск консоли… или нет!


Когда пользователь *NIX хочет запустить инструмент командной строки, то сначала запускает терминал. Тот затем запускает оболочку по умолчанию или может быть настроен для запуска определённого приложения/инструмента. Терминал и приложение командной строки взаимодействуют потоками символов через Pseudo TTY (PTY).

Однако в Windows всё работает иначе: пользователи Windows никогда не запускают консоль (conhost.exe) — они сразу запускают оболочки командной строки и приложения, например, Cmd.exe, PowerShell.exe, wsl.exe и прочее. Windows подключает запущенное приложение к текущей консоли (если оно запущено из командной строки) или к вновь созданному экземпляру консоли.

#SAYWHATNOW?

Да, в Windows пользователи запускают приложение командной строки, а не саму консоль.

Если пользователь запускает приложение командной строки из существующей оболочки командной строки, то Windows обычно присоединяет вновь запущенный .exe к текущей консоли. В противном случае Windows запустит новый экземпляр консоли, к которому будет присоединено только что запущенное приложение.

Немного занудства: многие говорят, что «приложения командной строки запускаются в консоли». Это не так и приводит к большой путанице относительно того, как в реальности работает консоль и приложения командной строки! Приложения командной строки и их консоли запускаются в независимых процессах Win32. Помогите исправить это заблуждение. Всегда говорите, что «средства командной строки/приложения выполняются с подключением к консоли». Спасибо!

Звучит неплохо, правда? На самом деле… нет. Есть некоторые проблемы:

  1. Консоль и приложение командной строки взаимодействуют сообщениями IOCTL через драйвер, а не через текстовые потоки
  2. Windows указывает, что ConHost.exe — это консольное приложение, подключенное к приложениям командной строки
  3. Windows создаёт «каналы» (pipes), по которым взаимодействуют консоль и приложение командной строки

Это существенные ограничения. Что если вы хотите создать альтернативное консольное приложение для Windows? Как отправить события с клавиатуры/мыши и прочие действия пользователя в приложение командной строки, если нельзя получить доступ к каналам, соединяющим консоль с этим приложением?

Увы, ситуация тут не очень хорошая. Есть отличные сторонние консоли и серверные приложения для Windows (например, ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH и т. д.), но им приходится прибегать к изощрённым трюкам, чтобы работать как обычная консоль!

Например, сторонним консолям приходится запускать приложение командной строки вне экрана, скажем, с координатами (-32000, -32000). Затем отправлять нажатия клавиш на внеэкранную консоль, скрапить с экрана текстовое содержимое внеэкранной консоли — и повторно выводить его в собственном пользовательском интерфейсе!

Какое-то безумие, верно?! Тот факт, что эти приложения вообще работают — лишь доказательство изобретательности и целеустремленности их создателей.

Очевидно, что мы стремимся исправить эту ситуацию. Об этом тоже расскажем в следующих статьях.

Windows Console и VT


Как описано выше, консоль Windows предоставляет богатый API. С помощью Console API приложения и инструменты командной строки пишут текст, изменяют его цвет, перемещают курсор и т.д. И благодаря этим API не нужно было поддерживать последовательности ANSI/VT, которые обеспечивают похожую функциональность на других платформах.

Фактически, до Windows 10 в консоли Windows была реализована только минимальная поддержка последовательностей ANSI/VT:



Всё изменилось в 2014 году, когда Microsoft сформировала новую группу разработки Windows Console. Одним из её главных приоритетов стало реализовать всестороннюю поддержку последовательностей ANSI/VT для визуализации выходных данных приложений *NIX, работающих в подсистеме Windows для Linux (WSL) и на удалённых машинах *NIX.

Группа быстро внедрила в консоль Windows 10 всестороннюю поддержку последовательностей ANSI/VT, что позволило пользователям использовать и наслаждаться огромным набором инструментов и приложений командной строки Windows и Linux.

Команда продолжает улучшать поддержку VT с каждым выпуском ОС и будет благодарна за любые проблемы, которые вы упомянете в нашем трекере на GitHub. ;)

Обработка Юникода


К сожалению, консоль Windows и её API появились до изобретения Юникода!

Консоль Windows хранит текст (который впоследствии выводится на экран) как символы кодировки UCS-2 с двумя байтами на символ. Эта кодировка поддерживает кодирование первых 65536 позиций символов, что известно как плоскость 0 или основная многоязычная плоскость (Basic Multilingual Plane, BMP).

Приложения командной строки выводят текст в консоли с помощью Console API. Обрабатывающие текст интерфейсы, бывают двух видов: функции с суффиксом А обрабатывают однобайтовые/символьные строки, функции с суффиксом W обрабатывают двухбайтовые (wchar)/символьные строки.

Например, функция WriteConsoleOutputCharacter компилируется в WriteConsoleOutputCharacterA() для проектов ASCII или в WriteConsoleOutputCharacterW() для проектов на Юникоде. Код может напрямую вызвать функцию с суффиксом ...A или ...W, если необходима обработка конкретного типа.

Примечание: каждый W API поддерживает UCS-2, потому что это всё, что существовало в момент разделения на A/W, и мы думали, что так будет хорошо. Но многие W API уже обновились для поддержки ещё и UTF-16 на том же канале.

Не все W API понимают UTF-16, но все они знают хотя бы UCS-2.

Кроме того, консоль не поддерживает некоторые новые функции Юникода, включая соединительные символы нулевой ширины (zero width joiner), которые используются для объединения отдельных символов в арабских и индийских письменностях, а также для объединения символов эмодзи в один визуальный глиф.

Как же ввести эмодзи кота-ниндзя или сложные многобайтовые китайские/арабские символы в консоль? К сожалению, никак!

Мало того что консольный API не поддерживает символы Юникод больше двух байт на глиф (эмодзи NinjaCat требует 8 байт!), но внутренний буфер UCS-2 консоли тоже не может хранить дополнительные байты данных. Что ещё хуже, текущий GDI-рендерер консоли не сможет отрисовать глиф, даже если тот поместится в буфер!

Эх… Таковы радости legacy-кода.

Здесь опять я намерен прервать рассказ — вернёмся к этой теме в следующей статье. Оставайтесь с нами!

Итак, на чём мы остановились?


Дорогой читатель, если вы прочитали всё вышенаписанное, спасибо вам, и примите поздравления — теперь вы знаете больше о консоли Windows, чем большинство ваших друзей, и, вероятно, даже больше, чем вы сами хотели узнать! Какая удача!

Мы многое рассмотрели в этой статье:

  • Основные строительные блоки консоли Windows:
    • Condrv.sys — коммуникационный драйвер
    • ConHost.ехе — UX консоли и механика:
      • Сервер API — сериализует вызовы API и текстовые данные с помощью сообщений IOCTL, отправляемых в/из драйвера
      • API — функциональность консоли
      • Буферы — буфер ввода, хранящий пользовательский ввод, и буфер вывода, хранящий выходной/отображаемый текст
      • Парсер VT — преобразует последовательности ANSI/VT из текстового потока в вызовы API
      • UX консоли — состояние UI консоли, настройки, функции
      • Другое — технические данные, безопасность и проч.
  • Что делает консоль
    • Отправляет пользовательский ввод в подключенное приложение командной строки
    • Получает и отображает выходные данные из подключенного приложения командной строки
  • Чем консоль отличается от терминалов *NIX
    • NIX: «Всё представляет собой файл/текстовый поток»
    • Windows: «Все представляет собой объект, доступный через API»
  • Проблемы консоли
    • Консольные приложения и приложения командной строки взаимодействуют через запросы вызовов API и текст, сериализованный в Сообщения IOCTL
    • Консольный API могут вызвать только приложения командной строки Windows
      • Сложнее портировать приложения на/из Windows
    • Приложения взаимодействуют с консолью через Windows API
      • Затрудняет удалённое взаимодействие с приложениями и средствами командной строки Windows
    • Зависимость от IOCTL нарушает схему «обмен символами» терминала
      • Затрудняет эксплуатацию инструментов командной строки удалённого с не-Windows машин
    • Запуск приложений командной строки Windows является «необычным»
      • К приложениям командной строки можно присоединить только ConHost.exe
      • Сторонние терминалы вынуждены создавать внеэкранную консоль, отправлять туда символы и скрапить экран
    • Windows исторически не понимает последовательности ANSI/VT
      • В основном исправлено в Windows 10
    • У консоли ограниченная поддержка Юникода и в настоящее время проблемы с хранением и рендерингом UTF-8 и глифов, которые нуждаются в соединительных символах нулевой ширины

В следующих нескольких статьях этой серии мы более подробно разберём консоль и обсудим решение этих проблем… и не только!

Как всегда, следите за обновлениями.
Поделиться публикацией
Комментарии 174
    +3
    Из исторических соображений логично было бы упомянуть о таких продуктах, как 4DOS/4NT. В своё время были замечательным компромиссом — богатый арсенал работы с командной строкой, плюс совместимость с родной ОС.

    Пока что первый вывод, который напрашивается по прочтении статьи — после всех мегаусилий Windows-консоль (в смысле реализации самого механизма работы с приложениями из командной строки) практически приблизилась к тому, что реализовано в Unix/Linux.
      +3
      Если я правильно уловил посыл статьи, идущий сквозь неё на всем протяжении — консоль *nix и консоль windows это вобще два разных зверя, из общего у них черный экран и мигающий курсор.
        +7

        Как пользователя инструмента, меня же это не должно волновать.
        Есть две машины, одна быстрая и красивая а про вторую есть много документов где объясняют почему она медленная и страшная. Я, конечно же, утрирую но общий посыл такой.
        В любом случаи спасибо автору за то что рассказал как там все внутри.

          +6
          Надеюсь в вашей аналогии *nix — быстрая и красивая?
            +1
            Одна быстрая и красивая, а вторая 40тонный самосвал. Пользователь выбрал быструю и красивую и встал под погрузчик… Вывод — инструмент надо выбирать под задачу, а не «я же девочка, я хочу красненькую».
          +1
          Неправильно, IMHO: в HappyEnd'е они воссоединяются «и все танцуют»
            +3
            Это ещё мягко сказано. Стандартные unix-правила работы подходят очень приблизительно. WriteFile/ReadFile не поддерживают unicode, нужно использовать специальные функции, но они не совместимы с перенаправлениями, по этому не выйдет запустить такую программу через powershell консоль удалённо. По умолчанию установлен растровый шрифт (содержащий символы кириллицы), по этому даже 100% корректный вывод может оставить на экране лишь пустоту и кракозябры. В WindowsXP (да, знаю, умерла и похоронена, но ведь есть ещё шанс встретить в дикой природе) нет документированных способов узнать какой шрифт установлен в консоли.
            Весело, в общем.
              0
              В общем да, но меня как пользователя должна в первую очередь беспокоить функциональность и удобство.

              Мне казалось, что синтаксис Bash не очень дружественный — ровно до того момента, когда начал часто работать с PowerShell. И что-то мне вдруг сразу припомнился Cobol…

              Про затейливые странные глюки PS уже упомянули в одном из соседних комментариев. Это к тому, что порой всё равно приходится использовать ещё и cmd.exe…

              А так да, основательно написано, с чувством.
                +2

                А у меня была противоположеная ситуация: bash казался вершиной консольной мысли пока powershell не увидел.

                  +2

                  У PS шаг вправо-шаг влево и натыкаешься на совершенно нечитаемые сообщения об ошибках и синтаксис очень многословный. Мне сначала PS тоже приглянулся, но за красивой оберткой горы граблей: и место шва между нативными и .net приложениями, и куча "защит", и зависимость от сторонних наборов скриптов.
                  Впрочем, разгребать скрипты на bash 5000 строк и более -тоже глазоломство неприятное.


                  А как gui мне таки нравится ZSH, особенно Oh My ZSH! с докрученными свистелками и гуделками.

                    0
                    Интереса ради, а где такие баш скрипты на 5000 строк водятся?
                      +2
                      Многие линуксовые приложения на самом деле являются скриптами на bash. Там бывает и 5k, и 10k строк. Впрочем, обычно проблема разгребания такого кода кроется не в bash, а в погромизде, который написал этот код.
                        +2

                        Где-где, в дикой природе и в кровавом энтерпрайзе :)
                        Ну, это, знаешь, начинается всё с одной затяжки небольшого скрипта для "подготовки проекта к сборке", потом в этом скрипте оказывается много текста и ты выносишь функции в отдельный, потом осознаёшь, что скриптов уже 15 и надо бы их рассовать по папочкам, оп-оп-оп… И через годик смотришь: "Какой чудила наворотил этого монстра?!" :)
                        Вон, например, минималистичный установщик Manjaro как раз примерно подобного масштаба. При этом он раз в 5 больше большинства установщиков Arch, а делает то же самое — всего-то чуть чуть вариативности и универсальности.

                    –1

                    В *nix системах можно выбрать любой shell из нескольких "из коробки" (bash, tcsh, etc) и даже написать свой. Благо компилятор с/с++ всегда под рукой. Причем скрипты для любого интерпретатора всегда доступны. И у каждого пользователя может быть свой shell. У MS одни только типы файлов привязанные к расширению вызывают лютую ненависть.

                      +1
                      Я много раз пытался взяться за изучение PowerShell и каждый раз тянет выкинуть книжку, не страдать фигней и пользоваться Bash'ем! Да, PowerShell мощный, временами необходимый, но длинный и некрасивый, неэлегантный какой-то, что сразу с порога отвращает.
                    0
                    Вроде как автор пытался донести что виндовая консоль намного удобнее идеологически, т.к. оперирует объектами а не текстом, который прийдётся чаще всего ещё и запарсить…
                      +1
                      4NT переименовали, и сейчас она называется:

                      C:\>ver
                      TCC 20.00.16 x64 Windows 10 [Version 6.3.14393]
                      C:\>

                      (это не последняя версия)

                      Использую до сих пор, подменяя переменную окружения ComSpec. Хотя, вероятно, уже пора переходить на что то встроенное, и присутствующее везде в win10 по умолчанию. Но, как правильно было замечено — «тяжкое наследие прошлого» в виде самописных .btm не дает быстро перестроиться.
                        0
                        Таки да, груз уже написанного не всегда позволяет взять и начать всё сызнова.
                          0
                          Можно попробовать родной cmd с дополнением conemu.
                          +1
                          И не только из исторических. Я и сейчас пользуюсь TCC LE — Take Command Console Light, в которую превратился 4NT.
                          +2
                          Отличная ретроспектива!
                          Консолью и *.cmd я пользовался только на NT4. Начиная с Win2K, все писал на VBScript под WSH. А вот для Win2K8 уже PowerShell и только PowerShell!
                            0
                            а также во все версии Windows Server, Windows Phone 7+, Xbox и HoloLens
                            Разве в WP7 не WinCE ещё было?
                              0
                              последнею WinСЕ помню под версией 6.x
                              windows mobile закончился на 6.5
                              а windows phone 7 это уже извращения по переносу nt на мобильную платформу. помню ходили картинки телефонов с ошибкой на черном экране, что мол не могу загрузить файл \windows\system32 press alt+ctrl+del.
                                0
                                WP7 все еще был на WinCE.
                                  0
                                  ну да, ядро там от СЕ, хотя система изрядно переработана.
                              +15
                              Чего только не придумают люди, что бы не пользоваться linux
                                +2
                                Лет 15-20 назад, читал замечательный рассказ «последний пользователь» (как-то так, прошу прощение за мой склероз) Канва истории — на планете все сидят на одной ОС, но вот человек купил себе ПК, юзает его (поф как, хоть в опкодах) но не хочет покупать себе всепланетную ОСь, его и так все устраивает, но это не устраивает акционеров корпорации добра, и к (тому человеку) прислали рекламного агента — он (рекл агент) стоя в дверях аж плачет — вы единственный у кого нет нашей замечательной программы! — а мне не нужно. -вам не нравится наша ОСь? — нравится, — но почему? — не хочу. (тут уместен кадр из «собачьего сердца» с продажей профессору Преображенскому журналов) — вы против прогресса? — непротив, — но почему? корпорация добра уполномочила подарить вам нашу программу, вы единственный, кто ей не пользуется! — не хочу и все.
                                  +3
                                  У меня вот с линуксом та же история. Не хочу и всё тут, все вокруг бегают, кричат, восхищаются, а мне не нравится. Вот фряха симпатичная, всё чего нельзя сделать под виндой, можно сделать там, но всем нужен проклятый линукс. Точнее каждому нужен какой-то свой, особенный, из сотен вариантов линукса. И это вгоняет меня в уныние.
                                    0
                                    «Сделайте систему, которой сможет пользоваться даже идиот — и только идиот захочет ей пользоваться».

                                    Есть некая грань популярности, после которой следует сползание софта в попсу — и вроде всем понятный, и удобный, но с этого момента обычно следует внедрение рюшечек и эмотиконов взамен развития в сторону функциональности.

                                    Возможно, относительно малая популярность — не так уж и плохо?
                                  0

                                  DOS, Windows, CP/M, OS/2, Solaris...

                                  +7
                                  16-битный недоюникод не поддерживающий стандарт Unicode, альтернативная система вывода (отличная от всего остального мира), слеши в путях не в ту сторону, аргументы командной строки, которые приложение должно парсить само…

                                  Прям комок боли. Осталось приклеить стикер «Windows», и готово.
                                    +1
                                    Слеши можно писать правильньіе, повершелл автоматом заменяет на свои.
                                      0
                                      Обычные слеши работают и в CMD.EXE, и даже в COMMAND.COM (правда, там несколько своеобразно), надо только имена файлов заключать в кавычки.
                                      По факту, DOS поддерживал обычные слеши в именах файлов с самого начала, но не в командном интерпретаторе.
                                      0
                                      слеши в путях
                                      Хорошо, если слеши. В японской и корейской Windows свои знаки.
                                        0
                                        А пример?
                                          0
                                          Заголовок спойлера

                                        +2
                                        Проблема с парсением аргументов полностью решена в PS. В классических консольных приложениях же, насколько я в курсе, ситуация не сильно отличается *nix-мира: частично решается при помощи стандартных RTL. Если писать на C, то аргументы будут вам переданы в main в виде (argc, argv) — правда, степень стандартизации их синтаксиса всё равно гораздо ниже, чем в PS.
                                          0
                                          слеши в путях не в ту сторону

                                          Меня всегда поражает уверенность линуксоидов в своей правоте. Они всегда знают, какие слеши правильные, а какие нет, какой должен быть порядок байтов и с какой стороны разбивать яйцо.
                                            +1
                                            А при чём тут linux'оиды? PDP/11 был задолго до появления Windows 1.0 и задолго по появления Linux.

                                            Ну как бы если бы кто-то настаивал, что в конце предложения надо ставить значок "ō" вместо точки. Все до него использовали ".", все кроме него используют "." и только он утверждает, что писать надо иначе ō
                                              +1
                                              Именно это я и имею в виду. Линуксоидов не интересуют исторические аспекты, потому что у них уже есть источник истины, который они сами же и выбрали.

                                              Кстати
                                              cd C:/Windows/System32/drivers/etc
                                                –1
                                                Ультимативное оправдание для любой фигни. «тогда так надо было, и тридцать лет спустя мы должны это продолжать». Причины и оправдания могут быть любые — на выходе-то эргономика использования сейчас.

                                                Комок легаси-совместимости с мёртвыми системами со стикером Windows. Такое определение лучше?
                                                  +1
                                                  Вы не можете понять одного: менять ничего не надо.
                                                    –1
                                                    Так никто и не меняет. setup.exe для windows 95 всё ещё существует. У всех остальных есть запросы на перемены.
                                                      –1
                                                      В чужой монастырь со своим уставом не ходят. Никто не может решать, какие слеши «правильнее».
                                                        +1
                                                        Вы⍀совершенно⍀правыāКаждый⍀может⍀использовать⍀такие⍀знаки⍀препинания°⍀какие⍀хочетāНикто⍀не⍀может⍀решать°⍀какие⍀знаки⍀! правильнее¡ā
                                                          0
                                                          Не, не так. Возьмите собой прибор с еворорозеткой и поезжайте в США. Похоже это единственный способ дать Вам понять, что я имею ввиду.
                                                          +2
                                                          Windows долго крутилась в своем монастыре со своими уставами, в результате полностью потеряла мобильный рынок и с трудом удерживает жалкий процент на серверном.

                                                          Сейчас до MS начало доходить, и они стали потихоньку внедрять стандарты, существующие уже несколько ДЕСЯТКОВ лет.
                                                  +1
                                                  Ну как бы если бы кто-то настаивал, что в конце предложения надо ставить значок "ō" вместо точки.

                                                  Японцы используют 。 если что. И они по своему правы.
                                                    –1
                                                    Они её используют в японском. Или у windows свой язык, не похожий на все остальные языки?
                                                      +1
                                                      Bat действительно является другим языком, отличным от шела Linux, впрочем как и PS, perl и прочее.
                                                +2
                                                Видите ли, не всем по нраву два раза жать ESC когда и с первого раза компьютеру должно быть понятно что от него хотят. И не всем программам подходит этот странный уговор, что регистровых клавиш как бы не существует на клавиатуре.

                                                Короче, свои бревна из глаз повынимайте сначала.
                                                  +1
                                                  Эм… Это про какую часть linux'а вы говорите? Вы случайно linux с mc не путаете?
                                                    +2
                                                    Но ведь у mc не просто же так такое поведение. У всего есть причина…
                                                      0
                                                      Если вы хотите из меня сделать защитника mc, fat chance. Унылый древний софт, в который даже патчи толком не принимают. Вполне себе ровня винде по легаси-нагрузке и способности адаптироваться к новым реалиям.
                                                      +2
                                                      При чем тут mc? Если терминал Linux в 2018 году использует ESC-последовательности, то это проблема не прикладного софта. Про невидимость для терминала регистровых клавиш только ленивый не писал.

                                                      Нельзя все многообразие этого мира запихнуть в семибитный символьный поток.
                                                      0
                                                      И не всем программам подходит этот странный уговор, что регистровых клавиш как бы не существует на клавиатуре.

                                                      Не путайте программы и протоколы.
                                                      Попробуйте реальную консоль линукса, а не эмуляции.

                                                      Или расскажите, как хорошо работают все хоткеи в винде через rdp, особенно если не фулл скрин?
                                                        +1
                                                        Не путайте программы и протоколы.
                                                        Попробуйте реальную консоль линукса, а не эмуляции.

                                                        Что есть реальная консоль? На физическом, работающем под управлением Linux компьютере, все то же самое.

                                                        Или расскажите, как хорошо работают все хоткеи в винде через rdp, особенно если не фулл скрин?

                                                        Если RDP не фулл скрин, то он обязан подчиняться общесистемному «поведенческому окружению», как любое другое окно любого другого приложения. Именно поэтому в оконной сессии не работает Alt+Tab и многое другое, ибо нельзя ломать look&feel хостовой системы, где ты простое окно.
                                                          +1
                                                          Реальной консолью он называет то, что видно по Ctrl+Alt+F1. В отличии от виртуальной которую дает xterm или ssh.

                                                          Другими словами, реальная консоль — это tty*, а виртуальная — pty*.

                                                          Но я все равно не понимаю при чем тут реальная консоль. На винде-то я FAR в окне открываю, а последний раз фулскрином пользовался еще в школе.
                                                            0
                                                            Реальной консолью он называет то, что видно по Ctrl+Alt+F1

                                                            Так там то же самое. Двойной ESC и игнор нажатий на регистровые клавиши. А кое-где даже стрелки не работают пока не пнешь в нужное место.
                                                            +1
                                                            Если RDP не фулл скрин, то он обязан подчиняться общесистемному «поведенческому окружению», как любое другое окно любого другого приложения. Именно поэтому в оконной сессии не работает Alt+Tab и многое другое, ибо нельзя ломать look&feel хостовой системы, где ты простое окно.
                                                            Есть проблема с хоткеями. Например, Ctrl+Alt+Up/Down, которое в моей IDE используется как найди следующее/предыдущее вхождение слова под курсором, не работает даже в полноэкранном режиме RDP.
                                                      +3
                                                      Совершенно неясно, зачем же гальванизировать труп чёрного прямоугольничка с белыми буковками. Что мешает придумать новую консоль, лучшую и архитектурно правильную, и пересадить на неё PowerShell? Старую можно оставить, пусть себе потихоньку фурычит. В случае же с переделкой существующей подсистемы консоли это впихивание невпихуемого вкупе с требованием ничего не сломать вызывает лёгкое недоумение.
                                                        0
                                                        Я думаю, причина в том, что она уже настолько старая, что пора бы и обновить функционал, но настолько популярная (читай — «часто и много где используется»), что до сих пор многим нужна.
                                                        Есть в мире такие «калеки» для которых по индивидуальным запросам мелкомягкие еще оказывают поддержку 95 и 98 винды, например. В случае с консолью этих калек столько, что проще запилить масштабную обнову, так как количество желающих пользоваться командной строкой не уменьшается с годами.
                                                          0

                                                          Проблема в протоколе взаимодействия программ.
                                                          Какая же архитектура лучше?

                                                            0
                                                            Универсальная лучше.
                                                            Текстовая — гораздо больше подходит под определение универсальной.
                                                            +1
                                                            Если PowerShell в новой консоли все равно будет перенаправлять объекты, а не текст, то особой разницы в прямоугольничке не будет…
                                                            +1
                                                            Опечатка в тексте. Символ «A» представляется кодом 0x41, а не 0x40.
                                                              0
                                                              fixed
                                                              +3
                                                              По поводу 24-х битного цвета в разных консолях и консольных программах рекомендую посмотреть обзорный GIST gist.github.com/XVilka/8346728
                                                                0
                                                                не перепутаны ли на картинке «Архитектура терминала и командной строки» в левой ее части input/output buffer?
                                                                  0
                                                                  Тоже самое подумал. Тупил в экран две минуты, глядя на это.
                                                                  +4
                                                                  Вот сделали новый powershell вместо cmd, а с кодировками 866 и 1251 все тот же ужас.
                                                                  захочешь простого Enter-PSSession
                                                                  а там
                                                                  PS C:\> Enter-PSSession host
                                                                  [host]: PS C:\Users\user\Documents> ping ya.ru

                                                                  ЋЎ¬Ґ­ Ї ЄҐв ¬Ё б ya.ru [87.250.250.242] б 32 Ў ©в ¬Ё ¤ ­­ле:
                                                                  ЋвўҐв ®в 87.250.250.242: зЁб«® Ў ©в=32 ўаҐ¬п=7¬б TTL=57
                                                                  ЋвўҐв ®в 87.250.250.242: зЁб«® Ў ©в=32 ўаҐ¬п=7¬б TTL=57
                                                                  ЋвўҐв ®в 87.250.250.242: зЁб«® Ў ©в=32 ўаҐ¬п=7¬б TTL=57
                                                                  ЋвўҐв ®в 87.250.250.242: зЁб«® Ў ©в=32 ўаҐ¬п=7¬б TTL=57

                                                                  ‘в вЁбвЁЄ  Ping ¤«п 87.250.250.242:
                                                                  Џ ЄҐв®ў: ®вЇа ў«Ґ­® = 4, Ї®«г祭® = 4, Ї®вҐап­® = 0
                                                                  (0% Ї®вҐам)
                                                                  ЏаЁЎ«Ё§ЁвҐ«м­®Ґ ўаҐ¬п ЇаЁҐ¬ -ЇҐаҐ¤ зЁ ў ¬б:
                                                                  ЊЁ­Ё¬ «м­®Ґ = 7¬бҐЄ, Њ ЄбЁ¬ «м­®Ґ = 7 ¬бҐЄ, ‘।­ҐҐ = 7 ¬бҐЄ
                                                                  [host]: PS C:\Users\user\Documents>

                                                                  а уж про Get-WinEvent вообще молчу
                                                                    0
                                                                    Увы. При вызовах консольных приложений без
                                                                    [Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-8')
                                                                    не обойтись.
                                                                      +1
                                                                      указание кодировок забавно работает
                                                                      проверяем локально из под пользователя
                                                                      Windows PowerShell
                                                                      © Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

                                                                      PS C:\> [Console]::OutputEncoding

                                                                      IsSingleByte: True
                                                                      BodyName: cp866
                                                                      EncodingName: Кириллица (DOS)
                                                                      HeaderName: cp866
                                                                      WebName: cp866
                                                                      WindowsCodePage: 1251
                                                                      IsBrowserDisplay: True
                                                                      IsBrowserSave: True
                                                                      IsMailNewsDisplay: False
                                                                      IsMailNewsSave: False
                                                                      EncoderFallback: System.Text.InternalEncoderBestFitFallback
                                                                      DecoderFallback: System.Text.InternalDecoderBestFitFallback
                                                                      IsReadOnly: True
                                                                      CodePage: 866

                                                                      PS C:\> [Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-8')
                                                                      Не удается вызвать метод. В этом языковом режиме вызов методов поддерживается только для основных типов.
                                                                      строка:1 знак:1
                                                                      + [Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-…
                                                                      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                      + CategoryInfo: InvalidOperation: (:) [], RuntimeException
                                                                      + FullyQualifiedErrorId: MethodInvocationNotSupportedInConstrainedLanguage

                                                                      а не работает из под пользователя
                                                                      локально из под админа
                                                                      Windows PowerShell
                                                                      © Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

                                                                      PS C:\> ping ya.ru -n 1

                                                                      Обмен пакетами с ya.ru [87.250.250.242] с 32 байтами данных:
                                                                      Ответ от 87.250.250.242: число байт=32 время=7мс TTL=57

                                                                      Статистика Ping для 87.250.250.242:
                                                                      Пакетов: отправлено = 1, получено = 1, потеряно = 0
                                                                      (0% потерь)
                                                                      Приблизительное время приема-передачи в мс:
                                                                      Минимальное = 7мсек, Максимальное = 7 мсек, Среднее = 7 мсек
                                                                      PS C:\> [Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-8')
                                                                      PS C:\> ping ya.ru -n 1

                                                                      Pinging ya.ru [87.250.250.242] with 32 bytes of data:
                                                                      Reply from 87.250.250.242: bytes=32 time=9ms TTL=57

                                                                      Ping statistics for 87.250.250.242:
                                                                      Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
                                                                      Approximate round trip times in milli-seconds:
                                                                      Minimum = 9ms, Maximum = 9ms, Average = 9ms

                                                                      поменялась локаль приложения, почему, зачем, непонятно

                                                                      пробуем Enter-PSSession
                                                                      Enter-PSSession
                                                                      Windows PowerShell
                                                                      © Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

                                                                      PS C:\> [Console]::OutputEncoding

                                                                      IsSingleByte: True
                                                                      BodyName: cp866
                                                                      EncodingName: Кириллица (DOS)
                                                                      HeaderName: cp866
                                                                      WebName: cp866
                                                                      WindowsCodePage: 1251
                                                                      IsBrowserDisplay: True
                                                                      IsBrowserSave: True
                                                                      IsMailNewsDisplay: False
                                                                      IsMailNewsSave: False
                                                                      EncoderFallback: System.Text.InternalEncoderBestFitFallback
                                                                      DecoderFallback: System.Text.InternalDecoderBestFitFallback
                                                                      IsReadOnly: True
                                                                      CodePage: 866

                                                                      PS C:\> Enter-PSSession host
                                                                      [host]: PS C:\Users\naves\Documents> [Console]::OutputEncoding

                                                                      IsSingleByte: True
                                                                      BodyName: koi8-r
                                                                      EncodingName: Кириллица (Windows)
                                                                      HeaderName: windows-1251
                                                                      WebName: windows-1251
                                                                      WindowsCodePage: 1251
                                                                      IsBrowserDisplay: True
                                                                      IsBrowserSave: True
                                                                      IsMailNewsDisplay: True
                                                                      IsMailNewsSave: True
                                                                      EncoderFallback: System.Text.InternalEncoderBestFitFallback
                                                                      DecoderFallback: System.Text.InternalDecoderBestFitFallback
                                                                      IsReadOnly: True
                                                                      CodePage: 1251

                                                                      [host]: PS C:\Users\naves\Documents> [Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-8')
                                                                      Исключение при задании «OutputEncoding»: «Неверный дескриптор.
                                                                      »
                                                                      строка:1 знак:1
                                                                      + [Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-…
                                                                      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                      + CategoryInfo: NotSpecified: (:) [], SetValueInvocationException
                                                                      + FullyQualifiedErrorId: ExceptionWhenSetting

                                                                      удаленная кодировка по умолчанию или koi8-r или 1251, вообще непонятно, и нельзя ее вот так просто взять и поменять
                                                                      0

                                                                      с кодировками всегда ужас. особенно, с однобайтовыми

                                                                        0
                                                                        Дык ping — это не коммандлет PS, а обычный консольный экзешник, с выдачей результата через стандартный вывод. А обмен через stdin/stdout всегда был в однобайтовых кодировках. Так что эти проблемы — результат необходимости поддержки древнего до-Юникодовского наследства, а не дефект PS или виндовой консоли. Кстати, Юникодовские функции для работы с консолью в Windows существуют очень давно (думаю, минимум с NT 4.0), но — это не stdin/stdout, и результат вывода через них нельзя перенаправить в файл или другой процесс.
                                                                          0
                                                                          Это дефект архитектуры, заключающийся в том, в системе одновременно активны две однобайтовые кодировки — ANSI и OEM. Если бы в русской локали было жёстко без вариантов Win-1251 или CP866, не было бы этой проблемы.
                                                                            +2
                                                                            А если локаль вообще не русская? Человек в своём примере демонстрирует запуск классического консольного экзешника в PS-сессии на удалённом хосте. При этом локаль запускаемого экзешника может не соответствовать ни локали клиента, ни локали сервера. Проблема в том, что ввод-вывод через stdin/stdout/stderr всегда рассматривался как текст в однобайтовой кодировке, а способов сигнализации используемой кодировки не существует. И PS решить эту проблему в классических консольных приложениях не может — он предлагает принципиально иной подход со своей object pipe, решающий и эту проблему, и другие.
                                                                              +1
                                                                              Это — дефект Powershell, вызванный отсутствием способа указать кодировку выхода вызываемой программы. Любые байты пришедшие с stdout преобразуются в последовательность строк, после чего прочитать их в правильной кодировке уже невозможно.
                                                                                +1
                                                                                Тут ещё накладывается unix-принцип, что stdin/stdout может быть бинарным потоком (например, у tar/gzip/compress). В этом сценарии преобразования категорически недопустимы.
                                                                                  0
                                                                                  Это не дефект PowerShell. Механизм обмена через stdin/stdout появился, когда Windows ещё не было даже в планах, и остался с тех пор практически в неизменном виде.
                                                                                    0
                                                                                    Но что мешало добавить в Powershell указание кодировки?
                                                                                      +1
                                                                                      Ну ё-моё. В самом PS указание кодировки не нужно — он построен вокруг .Net, где строки — в UTF-16. Проблема не в PS, а в том, что сотни тысяч, если не миллионы, классических экзешников, общающихся с внешним миром через стандартный ввод-вывод, не имеют способа указания кодировки. Они её не могут указать никому — ни PS, ни cmd.exe, ни драйверу файловой системы, если stdout перенаправлен в файл. Они просто открывают stdout и записывают в него поток однобайтовых символов в своей текущей кодировке. В принципе, кодировка может быть и не однобайтовой, и это даже может быть не текст, а двоичные данные. Но стандартного способа сигнализации об этом нет — ни в виндах, ни в *nix. Чтобы решить эту проблему, надо менять не только PS, но и переписывать все экзешники, использующие стандартный ввод-вывод.
                                                                                        0
                                                                                        Нужно! Вот именно по той причине что он построен вокруг .Net, где строки — в UTF-16.

                                                                                        От других программ он получает поток байт, который преобразует в последовательность строк в UTF-16. Вот на этом этапе и нужен механизм указания кодировки.
                                                                                          0
                                                                                          И как может выглядеть этот «механизм указания кодировки», если другие программы эту информацию не выдают ни в каком виде?
                                                                                            +1
                                                                                            А, только сейчас дошло — вы имеете в виду указание кодировки руками? Это делается, правда, не сильно удобно.
                                                                                              0

                                                                                              Расскажите сразу уж, как.

                                                                                                0
                                                                                                Вот, например, был пост здесь же на Хабре: habr.com/post/321076
                                                                                                Сам, правда, всё это не проверял.
                                                                              +7

                                                                              Так много слов, чтобы объяснить, как можно в виндовой консоли напечатать эмодзи котика-ниндзя?

                                                                                +6
                                                                                Мне показалось, что в статье много слов о том, что котика нарисовать таки нельзя.
                                                                                  +1

                                                                                  ХА ХА ХА!!! Всмысле, мяу. >^.^<

                                                                                –9
                                                                                Сегодня (середина 2018 года) WSL запускает большинство двоичных файлов Linux, программы, компиляторы, компоновщики, отладчикии т.д. Многие разработчики, IT-специалисты, инженеры DevOps и многие другие, кому необходимо запускать или создавать инструменты, приложения, службы Linux и т. д., получили резкое повышение производительности и возможность запускать свои любимые инструменты Linux вместе с любимыми инструментами для Windows на одном компьютере, без загрузки двух операционных систем.

                                                                                Я всегда с пренебрежением относился к Windows, про Билл Гейтса говорил, что он достоин Нобелевской премии за просвящение в области IT, и страшных кар за то, что беспрецендентное насаждение Windows в нашей стране, вернее в госорганах.
                                                                                Но после того как я попробал WSL, я сказал, что Билл Гейтс, его команда достойны уважения.

                                                                                  0
                                                                                  Так и вижу Билла Гейтса, ходящим по кабинетам госдумы, совета федерации и фсб и прямо-таки насаживающим Windows.

                                                                                  Да и к WSL он имеет отношение весьма посредственное.
                                                                                    +1
                                                                                    Да и к WSL он имеет отношение весьма посредственное.

                                                                                    Но имеет же

                                                                                      +1
                                                                                      Какое?
                                                                                        –1
                                                                                        он имеет отношение весьма посредственное.
                                                                                  +3
                                                                                  недоразвитость консоли в win10 помоему напрямую растет изза ограниченности Console API или закрытости драйвера консоли. в частности если бы этот API позволял приложению (а не только kernel драйверу) получать иформацию что порожденное приложение рисует небыло бы проблем сторонним разработчикам писать свои консоли и расширения. но сейчас там одни костыли и попытка перехватить нужную информацию через dll injection (смотрим ConEmu), тормозит и глючит. столько воды в статье налито, а побольшому счету надо драйвер консоли в системе сделать открытым и создать экосистему для сторонних расширений, имхо.
                                                                                    +1

                                                                                    недоразвитость консоли в win растет из-за драконовских требований прямой и обратной совместимости: консоль является одной из главных подсистем ОС, и написаны тысячи и тысячи консольных приложений, которые должны работать в консоли — иначе кому нужна консоль с двумя с половиной приложениями?
                                                                                    таким образом, мы либо творим чудеса и сохраняем совместимость, улучшая консоль, либо переписываем все приложения, адаптируя к улучшениям консоли.
                                                                                    таким образом, хоть изначально подход windows console лучше (структура более целостна, чем поток), но подход *nix "всё есть файл"(а точнее, символьный поток) позволяет обогащать возможности при сохранении совместимости ("простое лучше сложного") и взаимодействовать совершенно разным стстемам и программам.


                                                                                    что значит, что открытие ядра не решит проблему.
                                                                                    и подтверждение тому — куча сторонних разработок типа ConEmu, которые все равно глючат и тормозят.

                                                                                      +2
                                                                                      обратная совместимость не мешает дать API разработчикам чтобы перехватить все операции с консолью. но такого API нет, полная информация доступна только драйверу и он закрыт, вот и делают в ConEmu и им подобным перехват работы с консолью через dll injection что сложно, глючит. тормозит ConEmu так как ему приходится через поллинг сканировать консоль на изменения…
                                                                                      в *nix в этом плане все конечно лучше, но дело не только в «все устройства — файл» а именно в открытой имплементации. пока api фактически не предусматривает возможность замены драйвера консоли на свою имплементацию — все равно файл или 101 функция из dll.
                                                                                        0
                                                                                        Допустим, сделают они API для собственной реализации Console Host, но им воспользуется 2.5 проекта. Но затрат — море (документирование, поддержка обратной совместимости). ИМХО, это экономически невыгодно. Куча людей в MS будет работать не на нужды тысяч разработчиков, как с обычно бывает с API, а на эти 2.5 проекта.
                                                                                          0
                                                                                          Не видя код трудно сказать как тяжело его расширить. Но в статье упоминается что под консоль выделена команда, допустим 5-10 человек и наверняка с американскими зарплатами. Вон пишут пространные статьи о том как «корабли бороздят» и рефакторят ради рефакторинга (гы). Напишут ли они хорошую консоль — неизвестно, но миллион и больше бюджет за год съедят точно. :)

                                                                                          С моей точки зрения им надо создать вход в систему для сторонних разработчиков в первую очередь а не пытатся строить звездолет. Покрайней мере надеюсь что они новую консоль отправят в свободное плаванье опен-сурса, и документация тогда кстати говоря ненужна (как пример — msbuild задокументирован формально а по существу чтобы что то понять надо открывать код, блоги форумы и так далее).
                                                                                    0
                                                                                    Ради юниксовых команд перейти на Win 10?! А почему не на Wine?
                                                                                      0
                                                                                      А почему не на Wine?

                                                                                      Переходите на Wine под Windows, делов то )
                                                                                      +2
                                                                                      Преимущества консоли не только в написании команд и скриптов, а еще и в экономии аппаратных ресурсов.

                                                                                      Одно дело конфигурировать в черной страшной текстовой консоли, систему, которая занимает 500 Мб вместе с установленным софтом, и куда мы подключились находясь за несколько тысяч километров физически через мобильник с GPRS. И совсем другое консолить на 20-гигабайтной системе с 3D-тенями на окошках, сглаживании шрифтов и прочими красивыми плюшками. Тогда уж лучше ставить галочки мышкой.

                                                                                      Кстати вопрос: вот у меня есть Windows 10 на первом компьютере, и Windows 10 на втором компьютере. Как мне подключиться с одной в другую, не вызывая при этом рабочий стол, а именно с консоли в консоль? Так можно?
                                                                                        0
                                                                                        Кстати вопрос: вот у меня есть Windows 10 на первом компьютере, и Windows 10 на втором компьютере. Как мне подключиться с одной в другую, не вызывая при этом рабочий стол, а именно с консоли в консоль? Так можно?

                                                                                        Можно взять для этого PsExec
                                                                                        В самом простом виде — на первой машине в cmd выполняем что-то а-ля
                                                                                        psexec \\имя_второй_машины cmd
                                                                                        и получаем желаемое.
                                                                                        В PowerShell'е же подобный функционал есть из коробки.
                                                                                          –1
                                                                                          Насколько я помню, есть более «гуманный» способ. в системных компонентах Windows присутствуют Telnet-клиент и Telnet-сервер. Соответственно, на одной машине нужно включить сервер, на другой клиент и подключиться через cmd командой telnet…
                                                                                            0
                                                                                            не секьюрно
                                                                                              –2
                                                                                              За что минусанули то, если ваш комментарий вводит в заблуждение. Что имеете ввиду под «секьюрностью» (безопасностью)? Telnet при подключении типа Windows-Windows требует авторизации с использованием учетной записи пользователя.
                                                                                              В целях эксперимента давным-давно отправлял e-mail через smtp.yandex.ru, посредством telnet, с авторизацией.
                                                                                              Какие именно претензии к безопасности telnet-протокола?
                                                                                                +4
                                                                                                Вся информация, включая пароли, передаётся открытым текстом. Следовательно, если кто-то незаметно включится в свитч локальной сети (или при передаче через интернет он где-то находится по пути передачи данных), то всё прочитает.
                                                                                                  0
                                                                                                  Предложенный выше psexec разве шифрует логин и пароль? Вариант с Telnet предложен как альтернатива использованию psexec, который также использует УЗ Windows и поднимает там собственную службу для подобных подключений. По сути это и есть полный аналог telnet, только умеет копировать себя на удаленный компьютер и запускаться как служба, если конечно достаточно прав.
                                                                                                    +1
                                                                                                    psexec работает через smb, который в свою очередь использует ntlm или даже kerberos (если оба компьютера в домене). В любом случае пароль открытым текстом не передается, то есть хотя бы от пассивного прослушивания защита полная.
                                                                                                      0
                                                                                                      Спасибо за уточнение. Если имеется ссылка на статью, содержащую информацию о внутреннем устройстве данной утилиты, то буду благодарен.
                                                                                                +1
                                                                                                Самые прямые, там нет никакого шифрования, любой хацкер с WireShark/tcpdump посредине и у него все данные учётной записи и введённые команды.
                                                                                                  0
                                                                                                  Telnet передаёт все данные в виде открытого текста (в т.ч. и пару логин-пароль при авторизации) без какого бы то ни было шифрования.
                                                                                                    –1
                                                                                                    Подключем шифрованный VPN между двумя машинами и имеем шифрованный канал.
                                                                                                    ТАк что секурность вопрос организации, а не отдельного приложения.
                                                                                                      0
                                                                                                      И, внезапно, любые дырявые браузеры становятся безопасными, т.к. нечего по непонятным сайтам шастать, всё это вопрос организации, оказывается.
                                                                                                        +1
                                                                                                        Совершенно верно. С середины 2000 не пользуюсь антивирусами. Не ловил вирусню даже когда жил под виндой.
                                                                                                          0
                                                                                                          То есть про различные уязвимости с smb, или про Petya вы не слышали и не читали?
                                                                                                          +2
                                                                                                          И тогда всё успешно прослушивает владелец VPN-сервера. Хорошо, если владельцем является доверенный админ, но всё ж проще взять обычный SSH, в котором все проблемы безопасности давно решены и VPN не нужен
                                                                                                            0
                                                                                                            А что, есть люди в современной России которые до сихо пор не обзавелись своим VPN?? :)
                                                                                                              0
                                                                                                              А зачем, лично мне вполне хватает SSH, его же использую и для обхода блокировок тоже :)
                                                                                                        +2
                                                                                                        Я никого не минусовал. Ну и минус к комментарию, это не «минусанули».
                                                                                                      +1
                                                                                                      Сударь нашел машину времени и вернулся в прошлое?
                                                                                                      0

                                                                                                      Вопрос на ту же тему: можно ли как-то из консоли запущенной на одной Windows 10 подключиться к консоли на другой Windows 10, в которой уже запущено некое консольное же приложение?
                                                                                                      Иными словами, есть ли какой-нибудь аналог GNU Screen под Windows?

                                                                                                        0
                                                                                                        а теперь запустите в сессии PsExec например FAR или Vim…
                                                                                                          +2
                                                                                                          Я не видел, чтобы автор оригинального вопроса запрашивал такой «функционал», а т.к. даром чтения мыслей не обладаю — то и способ был предложен максимально простой. Если он не подходит уже конкретно для вашей ситуации — какие тут ко мне претензии?
                                                                                                        0
                                                                                                        В Windows 10 уже завезли OpenSSH (клиент вроде бы предустановлен, сервер нужно включить в компонентах и настроить, сам не пробовал)
                                                                                                          +1
                                                                                                          Там огромные проблемы с безопасностью, именно поэтому его не берут в upstream, хоть бравые парни из MS собирались всё написать за пару месяцев и закинуть в upstream до конца 2016 года.

                                                                                                          Разработчики никогда не слышали про современные наилучшие практики безопасности, что для базового инструмента обеспечения безопасности довольно странно.

                                                                                                          Сам по себе продукт официально является Beta-версией и тянет за собой, насколько я помню, установку сырых PowerShell Core и .Net Core, которые ещё и будут сосуществовать у вас на компьютере с нормальными PowerShell и .NET.

                                                                                                          Потестировать — можно, рекомендовать это для нормальной работы я бы не стал.
                                                                                                          0
                                                                                                          есть некий winrm
                                                                                                          –1
                                                                                                          Читал и вспоминал, да что там вспоминал — чувствовал боль программирования под win32.
                                                                                                          MSDN с его табличками какие API поддерживаются в каких версиях W, скупые советы как обходить баги фичи конкретной версии W.
                                                                                                            +1

                                                                                                            всего лишь надо добавить префикс U

                                                                                                              +1
                                                                                                              Действительно, не то что на Linux, где изменение LibC ломает половину софта.
                                                                                                                0
                                                                                                                Ну так кто мешает держать несколько libC для разных версий софта? Или вообще вариант snap/flatpak, когда софт сам тащит с собой нужную версию.
                                                                                                                  –1
                                                                                                                  Эта проблема не так актуальна — дистрибутивы собираются под конкретные версии, да и пересобрать самому вообще не проблема — в мире unix динамические бинари никто не переносит между разными дистрибутивами.
                                                                                                                  А также есть развитая система автоконфигурирования (autoconf/automake).
                                                                                                                    +3
                                                                                                                    > да и пересобрать самому вообще не проблема

                                                                                                                    Ага, вообще ни разу не проблема. Пока компилятор/линкер ошибками сыпать не начнёт, а ты программист не настоящий, только маску нашёл.
                                                                                                                +2
                                                                                                                Напомнило добрые времена BBS и Fidonet
                                                                                                                  –1
                                                                                                                  рука-нога
                                                                                                                    0
                                                                                                                    Мне всегда казалось, что проблема в подходе к написанию системы.
                                                                                                                    В Linux консоль первична, «всё есть файл», и все наработки опираются на консоль.
                                                                                                                    В Windows консоль — не основа системы, а приделанный сбоку функционал. Не знаю как сейчас, но раньше в Windows некоторые вещи вообще нельзя было сделать через консоль — только через графический интерфейс.

                                                                                                                    Кстати, в статье упоминаются проблемы с парсингом вывода консольных утилит в никсах. Неужели на каком-то этапе развития нельзя было перейти к выводу данных в xml? Или переходу от «всё есть файл» к «всё есть файл или директория», который позволил бы получать конкретные значения и использовать, так сказать, «объектный подход»?
                                                                                                                      +1
                                                                                                                      «Проблемы», указанные в статье — полная фигня по сравнению с проблемами в использовании Win10, причем дело не только в терминале.
                                                                                                                        0
                                                                                                                        Это с какими?
                                                                                                                          +2
                                                                                                                          Неотключаемая (почти) слежка за пользователем, постоянные обновления, которые насмерть вешают мой комп 4-летней давности, а потом его перезагружают, запарывание ntfs установкой «грязного» флага при выключении так, что ntfs-3g отказывается его монтировать, проблемы с драйверами ну и под конец моего общения с этой недовиндой просто перестал открываться «Пуск». В итоге решил не переустанавливать, а снести с компа, дать побольше места линуксу и запускать W7 в виртуалке из-под него. Бррр.
                                                                                                                            0
                                                                                                                            мой комп 4-летней давности

                                                                                                                            Мой комп обр.2015 (конца) еще лет 7 точно прослужит и никакая ОС его не повесит.
                                                                                                                            Секрет? Уверен на 95%, что вы в таком случае взяли железо предельно не вовремя, на самом излете актуальности стэка ddr3.
                                                                                                                            Моя станция так же не вчера взята, однако NVMe (до 32ГБит/сек), 64Гб ОЗУ, 24+8Гб GPU, никакого свопа. Технологии в тот момент совершили очень резкий скачок.
                                                                                                                              +1
                                                                                                                              Да, это так. Сейчас я понимаю, что нужно было чуть-чуть подождать и купить DDR4, проц посвежее, SSD вместо харда, ну и далее по списку. Но проблема в том, что в тот момент умер верный комп образца 2007 года (в связи с накрывшимся БП), и новый был нужен уже прямо вот сейчас.
                                                                                                                              Тем не менее, и Debian, и NixOS позволяют одновременно слушать музыку, компилить проект, и виртуалке тестить клиент под windows 7, а 10ка, хотя и работает, вешает комп намертво при обновлениях (а иногда и просто так), поэтому работать невозможно.
                                                                                                                                0
                                                                                                                                Чисто в рамках «помочь» — комплект из одной плашки ddr4 16Gb + материнка Asus + Ryzen 2600 + NVMe M.2 Samsung сейчас в тысяч 40 кажется укладывается.
                                                                                                                                Я понимаю, что у кого-то может быть такой целая зарплата, у кого-то ипотека/долги, есть семья. Но все-таки это не такая неподъемная сумма (для IT), чтобы прям страдать — верю, что на сейчас у вас есть возможность сделать так, чтобы еще много лет более не страдать.

                                                                                                                                Серьезно, я как познакомился с М.2 дисками, так понял, что классические SSD прошлый век, близко не стоят к новому поколению.

                                                                                                                                P.S. Забавно, что я свою платформу чуть позже вас сменил. А исходный у меня был точно так же чуть моложе — 2008-го, на 775 сокете с Core Quad… хороший был комп, надежный боевой товарищ для своего времени.
                                                                                                                                  +1
                                                                                                                                  Пока что никаких страданий нет — linux летает на 8GB DDR3+512GB HDD+i5, и его хватает для 90% повседневных задач, а поддержку Windows 7 еще не закончили, так что пусть себе живет в виртуалке и дальше.
                                                                                                                        +1
                                                                                                                        Проблемы с парсингом текста — меньшее из зол. Unix-идеология подталкивает разработчиков выбирать такой формат вывода, чтобы он был удобным как для чтения человеком так и для парсинга примитивными инструментами. Кому сильно нужно отдают в данные структурированном виде или используют perl, python и т.п. Директории конечно есть, куда без ник.
                                                                                                                          0
                                                                                                                          XML младенец, по сравнению с консолью. Да и XML мягко говоря спасение, существуют более эффективные форматы: json, yaml, bson и тп. В классической unix консоли идет упор на читабельность и простоту.
                                                                                                                          Все равно, что бинарный registry и текстовые конфиги.
                                                                                                                          0

                                                                                                                          Кстати, а кто может объяснить причину того, что частенько вывод в консоль в винде замирает, фризя при этом само приложение и пока не нажмешь enter программа в терминале просто висит?

                                                                                                                            +1
                                                                                                                            Это происходит если пользователь случайно начал выделять текст в консоли
                                                                                                                              0
                                                                                                                              Так происходит, если случайно выделить что-нибудь в консоли. При нажатии enter выделение снимается и вывод консоли размораживается
                                                                                                                              +2
                                                                                                                              Здесь опять я намерен прервать рассказ — вернёмся к этой теме в следующей статье.
                                                                                                                              Узнаю стиль поддержки майкрософт:
                                                                                                                              — Как это сделать?
                                                                                                                              — Никак, мы обязательно вернемся к этому в следующий раз. Оставайтесь с нами!
                                                                                                                                0
                                                                                                                                А можно из PowerShell просто подключиться через SSH? Как в нормальной линуксоид консоли. Типа
                                                                                                                                ssh -v -p52000 user@server.ip
                                                                                                                                  +1
                                                                                                                                  Всегда можно было и из cmd, если ssh клиент лежит в %PATH%
                                                                                                                                    0
                                                                                                                                    Начиная с Windows 10 1709, в дополнительных компонентах можно включить клиент OpenSSH и использовать его в cmd и PowerShell.

                                                                                                                                    PS C:\Users\dr\Desktop> ssh -V
                                                                                                                                    OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
                                                                                                                                      0
                                                                                                                                      Отлично, спасибо. Приходится, к сожалению, работать сейчас на Windows и putty просто бесит.
                                                                                                                                        0
                                                                                                                                        Причём, начиная с Windows 10 1803 OpenSSH прекрасно работает в паре с KeeAgent. В 1709 были проблемы.
                                                                                                                                          0
                                                                                                                                          Блин, добавить в карму не могу, но это очень хорошая новость. Нам актуально.
                                                                                                                                        +1
                                                                                                                                        Не вижу я OpenSSH в дополнительнительных компонентах( Windows 10 Enterprise, version 1709, Build 16299.492
                                                                                                                                          +1
                                                                                                                                          Так и ставьте упомянутый в статье WSL. В store ищите убунту, весит меньше 200 метров, или другой дистр, там их несколько.
                                                                                                                                          Потом запускаем wsl.exe и радуемся не только ssh, но и apt, откуда всякого полезного наставить можно.
                                                                                                                                            0
                                                                                                                                            WSL нельзя. В домене зарезан Windows store
                                                                                                                                            +2
                                                                                                                                            А вы в каком управлении компонентами ставите, в таком или в таком? Нужно во втором, которое в новом интерфейсе настроек.
                                                                                                                                              +1
                                                                                                                                              Чертов винегрет десятки. Во втором вообще пусто в новых компонентах. Видимо, админы домена зарезали.
                                                                                                                                          0
                                                                                                                                          ssh можно найти рядом с git если у вас стоит Git for Windows
                                                                                                                                          0
                                                                                                                                          Спасибо за статью! Много нового узнал!

                                                                                                                                          P.S. На правах личного мнения. Без холивара! Мне кажется, что WSL — это извращенство высшей степени, т.к. windows ушла далеко от POSIX, да и блочные устройства — не нативное для ntfs, а значит, что всякие pipe и sock тоже будут работать с большим оверхедом. Поправьте, если неправ.
                                                                                                                                            +1
                                                                                                                                            От виртуальной машины оверхед будет ещё больше, как мне кажется.
                                                                                                                                              +1
                                                                                                                                              блочные устройства — не нативное для ntfs, а значит, что всякие pipe и sock тоже будут работать с большим оверхедом
                                                                                                                                              Не понял этот логический вывод…
                                                                                                                                              0
                                                                                                                                              А есть ли кроссплатформенные библиотеки для C++ для управления консолью, вывода всяких красивостей с поддержкой юникода, с хорошей поддержкой винды и т.п.?
                                                                                                                                              Стояла задача вывода цветного текста, перемещения курсора и т.п. для винды и линукса (без очистки всего экрана), так и не понял как это сделать.
                                                                                                                                                0
                                                                                                                                                ncurses?
                                                                                                                                                0
                                                                                                                                                (например, RS-232) со скоростью 10 символов в секунду (110 бод, бит в секунду, bps)

                                                                                                                                                Если у вас 8-битные символы, то UART стандарт, которыму аналогичен RS-232 потребует 100 «бит» в секунду: бит старта, 8 бит на символ, бит останова. Нет?
                                                                                                                                                  0
                                                                                                                                                  Вкладки и ссш клиент и сервер нормальный. Тогда можно будет поплеваться виндой пока допилят до достойного состояния консоль. Пока направление верное, но лучше остаться на линуксе. Меня тут никто не заставляет обновляться и перезагружаться принудительно. Когда хочу тогда верчу свою систему. Ну и это, заплатите за спутниковый трафик вашей телеметрии будьте добры, я против её передачи не только по соображениям безопасности, но и по финансовым.
                                                                                                                                                    +1

                                                                                                                                                    Статья оставляет сложные чувства. Ожидалось больше информации про собственно именно виндовую консоль, и её преимущества, которые позволяют, например, реализовать тот же Far Manager и другие приложения, юниксовым аналогам которых как до Луны. Прежде всего, это работа с непосредственно моделью клавиатуры и буфером экрана вместо отправки уже чересчур развесистых Esc-последовательностей. Скажем, он сразу же реагирует на нажатие, допустим, Ctrl и соответственно изменяет подсказки в нижней строке. Или позволяет иметь реакцию на Ctrl-Alt-Shift, допустим — в модели юниксовых терминалов такое принципиально невозможно. Я бы хотел, чтобы это портировали в иксы, а не наоборот...


                                                                                                                                                    Не все W API понимают UTF-16, но все они знают хотя бы UCS-2.


                                                                                                                                                    Кроме того, консоль не поддерживает некоторые новые функции Юникода, включая соединительные символы нулевой ширины (zero width joiner), которые используются для объединения отдельных символов в арабских и индийских письменностях, а также для объединения символов эмодзи в один визуальный глиф.
                                                                                                                                                    Как же ввести эмодзи кота-ниндзя или сложные многобайтовые китайские/арабские символы в консоль? К сожалению, никак!

                                                                                                                                                    Какое упущение! Оставьте так насовсем, пожалста! Ибо внесение эмодзи в Юникод было исторической ошибкой.

                                                                                                                                                      0
                                                                                                                                                      А что за терминал со вкладками на скринах? Какой то аналог ConEmu или тема на него?
                                                                                                                                                        0
                                                                                                                                                        Краем уха слышал, что в 1803 запилили какое-то автоматическое объединение окон приложений во вкладки. Возможно, это оно.
                                                                                                                                                          0
                                                                                                                                                          Это системные вкладки, только они еще не релизнулись. insider.windows.com/ru-ru/articles/introducing-sets

                                                                                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                                                        Самое читаемое