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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

А мне кажется, что это не какой‐то другой символ, это просто шрифт отображает слэши как иену.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так там то же самое. Двойной ESC и игнор нажатий на регистровые клавиши. А кое-где даже стрелки не работают пока не пнешь в нужное место.
Если RDP не фулл скрин, то он обязан подчиняться общесистемному «поведенческому окружению», как любое другое окно любого другого приложения. Именно поэтому в оконной сессии не работает Alt+Tab и многое другое, ибо нельзя ломать look&feel хостовой системы, где ты простое окно.
Есть проблема с хоткеями. Например, Ctrl+Alt+Up/Down, которое в моей IDE используется как найди следующее/предыдущее вхождение слова под курсором, не работает даже в полноэкранном режиме RDP.

Сочувствую. У меня была клавиатура, которая не поддерживала некоторые даже трёхклавишные комбинации, типа ctrl+alt+m (рефакторинг — выделить метод в Идее). Клавиатура! На ноутбуке. Тут самый идеальный терминал не поможет.


Ещё на Винде ctrl+alt+стрелки вообще экран крутили (idfxhk, чтоб мне таки было хорошо), но это я быстро пресёк.


А теперь слишком много системных (то ли оболочечных) сочетаний в Кубунте, из-за которых я не могу использовать в Идее любимые нумерованные закладки на цифрах — на цифры перенесён основной функционал с функциональных клавиш. Зато по ctrl+alt+f2..fn я могу "насладиться" труъ терминалом.


Я, впрочем, предпочитаю наслаждаться программированием. А что хоткеи разные на работе и дома — кушаю кактус, переключаю мозги, со скрипом, но переключаю. Всё-таки самое универсальное на моём рабочем месте — это (скромно потупившись) я.

При чём здесь клавиатура, если хоткей работает в IDE локально, но стоит зайти в RDP и запустить IDE в терминальной сессии, он уже не работает (с той же клавиатуры).
Ещё на Винде ctrl+alt+стрелки вообще экран крутили (idfxhk, чтоб мне таки было хорошо), но это я быстро пресёк.

Ну это свойство Интеловского видеодрайвера, а не Windows вообще. Причём, насколько помню, можно и изменить, и отключить.
Совершенно неясно, зачем же гальванизировать труп чёрного прямоугольничка с белыми буковками. Что мешает придумать новую консоль, лучшую и архитектурно правильную, и пересадить на неё PowerShell? Старую можно оставить, пусть себе потихоньку фурычит. В случае же с переделкой существующей подсистемы консоли это впихивание невпихуемого вкупе с требованием ничего не сломать вызывает лёгкое недоумение.
Я думаю, причина в том, что она уже настолько старая, что пора бы и обновить функционал, но настолько популярная (читай — «часто и много где используется»), что до сих пор многим нужна.
Есть в мире такие «калеки» для которых по индивидуальным запросам мелкомягкие еще оказывают поддержку 95 и 98 винды, например. В случае с консолью этих калек столько, что проще запилить масштабную обнову, так как количество желающих пользоваться командной строкой не уменьшается с годами.

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

Универсальная лучше.
Текстовая — гораздо больше подходит под определение универсальной.
Если PowerShell в новой консоли все равно будет перенаправлять объекты, а не текст, то особой разницы в прямоугольничке не будет…
не перепутаны ли на картинке «Архитектура терминала и командной строки» в левой ее части input/output buffer?
Тоже самое подумал. Тупил в экран две минуты, глядя на это.
Вот сделали новый 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 вообще молчу
Увы. При вызовах консольных приложений без
[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-8')
не обойтись.
указание кодировок забавно работает
проверяем локально из под пользователя
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, вообще непонятно, и нельзя ее вот так просто взять и поменять
Дык ping — это не коммандлет PS, а обычный консольный экзешник, с выдачей результата через стандартный вывод. А обмен через stdin/stdout всегда был в однобайтовых кодировках. Так что эти проблемы — результат необходимости поддержки древнего до-Юникодовского наследства, а не дефект PS или виндовой консоли. Кстати, Юникодовские функции для работы с консолью в Windows существуют очень давно (думаю, минимум с NT 4.0), но — это не stdin/stdout, и результат вывода через них нельзя перенаправить в файл или другой процесс.
Это дефект архитектуры, заключающийся в том, в системе одновременно активны две однобайтовые кодировки — ANSI и OEM. Если бы в русской локали было жёстко без вариантов Win-1251 или CP866, не было бы этой проблемы.
А если локаль вообще не русская? Человек в своём примере демонстрирует запуск классического консольного экзешника в PS-сессии на удалённом хосте. При этом локаль запускаемого экзешника может не соответствовать ни локали клиента, ни локали сервера. Проблема в том, что ввод-вывод через stdin/stdout/stderr всегда рассматривался как текст в однобайтовой кодировке, а способов сигнализации используемой кодировки не существует. И PS решить эту проблему в классических консольных приложениях не может — он предлагает принципиально иной подход со своей object pipe, решающий и эту проблему, и другие.
Это — дефект Powershell, вызванный отсутствием способа указать кодировку выхода вызываемой программы. Любые байты пришедшие с stdout преобразуются в последовательность строк, после чего прочитать их в правильной кодировке уже невозможно.
Тут ещё накладывается unix-принцип, что stdin/stdout может быть бинарным потоком (например, у tar/gzip/compress). В этом сценарии преобразования категорически недопустимы.
Это не дефект PowerShell. Механизм обмена через stdin/stdout появился, когда Windows ещё не было даже в планах, и остался с тех пор практически в неизменном виде.
Ну ё-моё. В самом PS указание кодировки не нужно — он построен вокруг .Net, где строки — в UTF-16. Проблема не в PS, а в том, что сотни тысяч, если не миллионы, классических экзешников, общающихся с внешним миром через стандартный ввод-вывод, не имеют способа указания кодировки. Они её не могут указать никому — ни PS, ни cmd.exe, ни драйверу файловой системы, если stdout перенаправлен в файл. Они просто открывают stdout и записывают в него поток однобайтовых символов в своей текущей кодировке. В принципе, кодировка может быть и не однобайтовой, и это даже может быть не текст, а двоичные данные. Но стандартного способа сигнализации об этом нет — ни в виндах, ни в *nix. Чтобы решить эту проблему, надо менять не только PS, но и переписывать все экзешники, использующие стандартный ввод-вывод.
Нужно! Вот именно по той причине что он построен вокруг .Net, где строки — в UTF-16.

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

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

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

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

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

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

Но имеет же

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

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


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

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

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

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

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

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

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

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

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

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

Потестировать — можно, рекомендовать это для нормальной работы я бы не стал.
UFO landed and left these words here
Читал и вспоминал, да что там вспоминал — чувствовал боль программирования под win32.
MSDN с его табличками какие API поддерживаются в каких версиях W, скупые советы как обходить баги фичи конкретной версии W.
Действительно, не то что на Linux, где изменение LibC ломает половину софта.
Ну так кто мешает держать несколько libC для разных версий софта? Или вообще вариант snap/flatpak, когда софт сам тащит с собой нужную версию.
Эта проблема не так актуальна — дистрибутивы собираются под конкретные версии, да и пересобрать самому вообще не проблема — в мире unix динамические бинари никто не переносит между разными дистрибутивами.
А также есть развитая система автоконфигурирования (autoconf/automake).
> да и пересобрать самому вообще не проблема

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

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

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

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

P.S. Забавно, что я свою платформу чуть позже вас сменил. А исходный у меня был точно так же чуть моложе — 2008-го, на 775 сокете с Core Quad… хороший был комп, надежный боевой товарищ для своего времени.
Пока что никаких страданий нет — linux летает на 8GB DDR3+512GB HDD+i5, и его хватает для 90% повседневных задач, а поддержку Windows 7 еще не закончили, так что пусть себе живет в виртуалке и дальше.
комплект из одной плашки ddr4 16Gb + материнка Asus + Ryzen 2600 + NVMe M.2 Samsung сейчас в тысяч 40 кажется укладывается.

Сейчас вспомнил про этот тред ибо внезапно умер мой нынешний комп (по причине наличия долбанутой собаки в доме) и я начал собирать новый… Получилась прям в точности эта конфигурация! Правда в 40000 не уложился, получилось 50000, но всё равно удивительное совпадение!
;)
Правда в 40000 не уложился, получилось 50000, но всё равно удивительное совпадение!

Ну, обсуждение велось летом (вот это же время летит — аж депрессия накатывает). А почти такой стац собирался в самом конце весны / начале лета. Сейчас цены опять скакнули (а на подходе «радости» «НДС 20%»/«снижение беспошлинного лимита» и прочее) :(

P.S. Хм, интересная видимо собака.
Проблемы с парсингом текста — меньшее из зол. Unix-идеология подталкивает разработчиков выбирать такой формат вывода, чтобы он был удобным как для чтения человеком так и для парсинга примитивными инструментами. Кому сильно нужно отдают в данные структурированном виде или используют perl, python и т.п. Директории конечно есть, куда без ник.
XML младенец, по сравнению с консолью. Да и XML мягко говоря спасение, существуют более эффективные форматы: json, yaml, bson и тп. В классической unix консоли идет упор на читабельность и простоту.
Все равно, что бинарный registry и текстовые конфиги.

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

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

PS C:\Users\dr\Desktop> ssh -V
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
Отлично, спасибо. Приходится, к сожалению, работать сейчас на Windows и putty просто бесит.
Блин, добавить в карму не могу, но это очень хорошая новость. Нам актуально.
Не вижу я OpenSSH в дополнительнительных компонентах( Windows 10 Enterprise, version 1709, Build 16299.492
UFO landed and left these words here
Чертов винегрет десятки. Во втором вообще пусто в новых компонентах. Видимо, админы домена зарезали.
Спасибо за статью! Много нового узнал!

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

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

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


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


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

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

А что за терминал со вкладками на скринах? Какой то аналог ConEmu или тема на него?
Краем уха слышал, что в 1803 запилили какое-то автоматическое объединение окон приложений во вкладки. Возможно, это оно.
Only those users with full accounts are able to leave comments. Log in, please.