*nix
Shells
API
Development for Windows
History of IT
Comments 180
+3
Из исторических соображений логично было бы упомянуть о таких продуктах, как 4DOS/4NT. В своё время были замечательным компромиссом — богатый арсенал работы с командной строкой, плюс совместимость с родной ОС.

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

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

+1
Одна быстрая и красивая, а вторая 40тонный самосвал. Пользователь выбрал быструю и красивую и встал под погрузчик… Вывод — инструмент надо выбирать под задачу, а не «я же девочка, я хочу красненькую».
+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
Таки да, груз уже написанного не всегда позволяет взять и начать всё сызнова.
+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.
UFO landed and left these words here
+2
Лет 15-20 назад, читал замечательный рассказ «последний пользователь» (как-то так, прошу прощение за мой склероз) Канва истории — на планете все сидят на одной ОС, но вот человек купил себе ПК, юзает его (поф как, хоть в опкодах) но не хочет покупать себе всепланетную ОСь, его и так все устраивает, но это не устраивает акционеров корпорации добра, и к (тому человеку) прислали рекламного агента — он (рекл агент) стоя в дверях аж плачет — вы единственный у кого нет нашей замечательной программы! — а мне не нужно. -вам не нравится наша ОСь? — нравится, — но почему? — не хочу. (тут уместен кадр из «собачьего сердца» с продажей профессору Преображенскому журналов) — вы против прогресса? — непротив, — но почему? корпорация добра уполномочила подарить вам нашу программу, вы единственный, кто ей не пользуется! — не хочу и все.
+3
У меня вот с линуксом та же история. Не хочу и всё тут, все вокруг бегают, кричат, восхищаются, а мне не нравится. Вот фряха симпатичная, всё чего нельзя сделать под виндой, можно сделать там, но всем нужен проклятый линукс. Точнее каждому нужен какой-то свой, особенный, из сотен вариантов линукса. И это вгоняет меня в уныние.
0
«Сделайте систему, которой сможет пользоваться даже идиот — и только идиот захочет ей пользоваться».

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

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

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

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


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


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


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

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

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

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

0
Универсальная лучше.
Текстовая — гораздо больше подходит под определение универсальной.
+1
Если PowerShell в новой консоли все равно будет перенаправлять объекты, а не текст, то особой разницы в прямоугольничке не будет…
+1
Опечатка в тексте. Символ «A» представляется кодом 0x41, а не 0x40.
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
Дык 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 ещё не было даже в планах, и остался с тех пор практически в неизменном виде.
+1
Ну ё-моё. В самом PS указание кодировки не нужно — он построен вокруг .Net, где строки — в UTF-16. Проблема не в PS, а в том, что сотни тысяч, если не миллионы, классических экзешников, общающихся с внешним миром через стандартный ввод-вывод, не имеют способа указания кодировки. Они её не могут указать никому — ни PS, ни cmd.exe, ни драйверу файловой системы, если stdout перенаправлен в файл. Они просто открывают stdout и записывают в него поток однобайтовых символов в своей текущей кодировке. В принципе, кодировка может быть и не однобайтовой, и это даже может быть не текст, а двоичные данные. Но стандартного способа сигнализации об этом нет — ни в виндах, ни в *nix. Чтобы решить эту проблему, надо менять не только PS, но и переписывать все экзешники, использующие стандартный ввод-вывод.
0
Нужно! Вот именно по той причине что он построен вокруг .Net, где строки — в UTF-16.

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

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

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

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

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

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

Но имеет же

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

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

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

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

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

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

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

Кстати, в статье упоминаются проблемы с парсингом вывода консольных утилит в никсах. Неужели на каком-то этапе развития нельзя было перейти к выводу данных в xml? Или переходу от «всё есть файл» к «всё есть файл или директория», который позволил бы получать конкретные значения и использовать, так сказать, «объектный подход»?
+1
«Проблемы», указанные в статье — полная фигня по сравнению с проблемами в использовании Win10, причем дело не только в терминале.
+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 еще не закончили, так что пусть себе живет в виртуалке и дальше.
0
комплект из одной плашки ddr4 16Gb + материнка Asus + Ryzen 2600 + NVMe M.2 Samsung сейчас в тысяч 40 кажется укладывается.

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

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

P.S. Хм, интересная видимо собака.
+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
Блин, добавить в карму не могу, но это очень хорошая новость. Нам актуально.
+1
Не вижу я OpenSSH в дополнительнительных компонентах( Windows 10 Enterprise, version 1709, Build 16299.492
UFO landed and left these words here
+2
А вы в каком управлении компонентами ставите, в таком или в таком? Нужно во втором, которое в новом интерфейсе настроек.
+1
Чертов винегрет десятки. Во втором вообще пусто в новых компонентах. Видимо, админы домена зарезали.
0
Спасибо за статью! Много нового узнал!

P.S. На правах личного мнения. Без холивара! Мне кажется, что WSL — это извращенство высшей степени, т.к. windows ушла далеко от POSIX, да и блочные устройства — не нативное для ntfs, а значит, что всякие pipe и sock тоже будут работать с большим оверхедом. Поправьте, если неправ.
+1
От виртуальной машины оверхед будет ещё больше, как мне кажется.
+1
блочные устройства — не нативное для ntfs, а значит, что всякие pipe и sock тоже будут работать с большим оверхедом
Не понял этот логический вывод…
0
А есть ли кроссплатформенные библиотеки для C++ для управления консолью, вывода всяких красивостей с поддержкой юникода, с хорошей поддержкой винды и т.п.?
Стояла задача вывода цветного текста, перемещения курсора и т.п. для винды и линукса (без очистки всего экрана), так и не понял как это сделать.
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 запилили какое-то автоматическое объединение окон приложений во вкладки. Возможно, это оно.
Only those users with full accounts are able to leave comments., please.