Комментарии 181
Из исторических соображений логично было бы упомянуть о таких продуктах, как 4DOS/4NT. В своё время были замечательным компромиссом — богатый арсенал работы с командной строкой, плюс совместимость с родной ОС.
Пока что первый вывод, который напрашивается по прочтении статьи — после всех мегаусилий Windows-консоль (в смысле реализации самого механизма работы с приложениями из командной строки) практически приблизилась к тому, что реализовано в Unix/Linux.
Пока что первый вывод, который напрашивается по прочтении статьи — после всех мегаусилий Windows-консоль (в смысле реализации самого механизма работы с приложениями из командной строки) практически приблизилась к тому, что реализовано в Unix/Linux.
Если я правильно уловил посыл статьи, идущий сквозь неё на всем протяжении — консоль *nix и консоль windows это вобще два разных зверя, из общего у них черный экран и мигающий курсор.
Как пользователя инструмента, меня же это не должно волновать.
Есть две машины, одна быстрая и красивая а про вторую есть много документов где объясняют почему она медленная и страшная. Я, конечно же, утрирую но общий посыл такой.
В любом случаи спасибо автору за то что рассказал как там все внутри.
Неправильно, IMHO: в HappyEnd'е они воссоединяются «и все танцуют»
Это ещё мягко сказано. Стандартные unix-правила работы подходят очень приблизительно. WriteFile/ReadFile не поддерживают unicode, нужно использовать специальные функции, но они не совместимы с перенаправлениями, по этому не выйдет запустить такую программу через powershell консоль удалённо. По умолчанию установлен растровый шрифт (содержащий символы кириллицы), по этому даже 100% корректный вывод может оставить на экране лишь пустоту и кракозябры. В WindowsXP (да, знаю, умерла и похоронена, но ведь есть ещё шанс встретить в дикой природе) нет документированных способов узнать какой шрифт установлен в консоли.
Весело, в общем.
Весело, в общем.
В общем да, но меня как пользователя должна в первую очередь беспокоить функциональность и удобство.
Мне казалось, что синтаксис Bash не очень дружественный — ровно до того момента, когда начал часто работать с PowerShell. И что-то мне вдруг сразу припомнился Cobol…
Про затейливые странные глюки PS уже упомянули в одном из соседних комментариев. Это к тому, что порой всё равно приходится использовать ещё и cmd.exe…
А так да, основательно написано, с чувством.
Мне казалось, что синтаксис 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 не дает быстро перестроиться.
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!
Консолью и *.cmd я пользовался только на NT4. Начиная с Win2K, все писал на VBScript под WSH. А вот для Win2K8 уже PowerShell и только PowerShell!
а также во все версии Windows Server, Windows Phone 7+, Xbox и HoloLensРазве в WP7 не WinCE ещё было?
НЛО прилетело и опубликовало эту надпись здесь
Лет 15-20 назад, читал замечательный рассказ «последний пользователь» (как-то так, прошу прощение за мой склероз) Канва истории — на планете все сидят на одной ОС, но вот человек купил себе ПК, юзает его (поф как, хоть в опкодах) но не хочет покупать себе всепланетную ОСь, его и так все устраивает, но это не устраивает акционеров корпорации добра, и к (тому человеку) прислали рекламного агента — он (рекл агент) стоя в дверях аж плачет — вы единственный у кого нет нашей замечательной программы! — а мне не нужно. -вам не нравится наша ОСь? — нравится, — но почему? — не хочу. (тут уместен кадр из «собачьего сердца» с продажей профессору Преображенскому журналов) — вы против прогресса? — непротив, — но почему? корпорация добра уполномочила подарить вам нашу программу, вы единственный, кто ей не пользуется! — не хочу и все.
У меня вот с линуксом та же история. Не хочу и всё тут, все вокруг бегают, кричат, восхищаются, а мне не нравится. Вот фряха симпатичная, всё чего нельзя сделать под виндой, можно сделать там, но всем нужен проклятый линукс. Точнее каждому нужен какой-то свой, особенный, из сотен вариантов линукса. И это вгоняет меня в уныние.
«Сделайте систему, которой сможет пользоваться даже идиот — и только идиот захочет ей пользоваться».
Есть некая грань популярности, после которой следует сползание софта в попсу — и вроде всем понятный, и удобный, но с этого момента обычно следует внедрение рюшечек и эмотиконов взамен развития в сторону функциональности.
Возможно, относительно малая популярность — не так уж и плохо?
Есть некая грань популярности, после которой следует сползание софта в попсу — и вроде всем понятный, и удобный, но с этого момента обычно следует внедрение рюшечек и эмотиконов взамен развития в сторону функциональности.
Возможно, относительно малая популярность — не так уж и плохо?
DOS, Windows, CP/M, OS/2, Solaris...
16-битный недоюникод не поддерживающий стандарт Unicode, альтернативная система вывода (отличная от всего остального мира), слеши в путях не в ту сторону, аргументы командной строки, которые приложение должно парсить само…
Прям комок боли. Осталось приклеить стикер «Windows», и готово.
Прям комок боли. Осталось приклеить стикер «Windows», и готово.
Слеши можно писать правильньіе, повершелл автоматом заменяет на свои.
слеши в путяхХорошо, если слеши. В японской и корейской Windows свои знаки.
Проблема с парсением аргументов полностью решена в PS. В классических консольных приложениях же, насколько я в курсе, ситуация не сильно отличается *nix-мира: частично решается при помощи стандартных RTL. Если писать на C, то аргументы будут вам переданы в main в виде (argc, argv) — правда, степень стандартизации их синтаксиса всё равно гораздо ниже, чем в PS.
НЛО прилетело и опубликовало эту надпись здесь
А при чём тут linux'оиды? PDP/11 был задолго до появления Windows 1.0 и задолго по появления Linux.
Ну как бы если бы кто-то настаивал, что в конце предложения надо ставить значок "ō" вместо точки. Все до него использовали ".", все кроме него используют "." и только он утверждает, что писать надо иначе ō
Ну как бы если бы кто-то настаивал, что в конце предложения надо ставить значок "ō" вместо точки. Все до него использовали ".", все кроме него используют "." и только он утверждает, что писать надо иначе ō
НЛО прилетело и опубликовало эту надпись здесь
Ультимативное оправдание для любой фигни. «тогда так надо было, и тридцать лет спустя мы должны это продолжать». Причины и оправдания могут быть любые — на выходе-то эргономика использования сейчас.
Комок легаси-совместимости с мёртвыми системами со стикером Windows. Такое определение лучше?
Комок легаси-совместимости с мёртвыми системами со стикером Windows. Такое определение лучше?
НЛО прилетело и опубликовало эту надпись здесь
Так никто и не меняет. setup.exe для windows 95 всё ещё существует. У всех остальных есть запросы на перемены.
НЛО прилетело и опубликовало эту надпись здесь
Вы⍀совершенно⍀правыāКаждый⍀может⍀использовать⍀такие⍀знаки⍀препинания°⍀какие⍀хочетāНикто⍀не⍀может⍀решать°⍀какие⍀знаки⍀! правильнее¡ā
Windows долго крутилась в своем монастыре со своими уставами, в результате полностью потеряла мобильный рынок и с трудом удерживает жалкий процент на серверном.
Сейчас до MS начало доходить, и они стали потихоньку внедрять стандарты, существующие уже несколько ДЕСЯТКОВ лет.
Сейчас до MS начало доходить, и они стали потихоньку внедрять стандарты, существующие уже несколько ДЕСЯТКОВ лет.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Эм… Это про какую часть linux'а вы говорите? Вы случайно linux с mc не путаете?
И не всем программам подходит этот странный уговор, что регистровых клавиш как бы не существует на клавиатуре.
Не путайте программы и протоколы.
Попробуйте реальную консоль линукса, а не эмуляции.
Или расскажите, как хорошо работают все хоткеи в винде через rdp, особенно если не фулл скрин?
НЛО прилетело и опубликовало эту надпись здесь
Реальной консолью он называет то, что видно по Ctrl+Alt+F1. В отличии от виртуальной которую дает xterm или ssh.
Другими словами, реальная консоль — это tty*, а виртуальная — pty*.
Но я все равно не понимаю при чем тут реальная консоль. На винде-то я FAR в окне открываю, а последний раз фулскрином пользовался еще в школе.
Другими словами, реальная консоль — это tty*, а виртуальная — pty*.
Но я все равно не понимаю при чем тут реальная консоль. На винде-то я FAR в окне открываю, а последний раз фулскрином пользовался еще в школе.
Если 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 винды, например. В случае с консолью этих калек столько, что проще запилить масштабную обнову, так как количество желающих пользоваться командной строкой не уменьшается с годами.
Есть в мире такие «калеки» для которых по индивидуальным запросам мелкомягкие еще оказывают поддержку 95 и 98 винды, например. В случае с консолью этих калек столько, что проще запилить масштабную обнову, так как количество желающих пользоваться командной строкой не уменьшается с годами.
Проблема в протоколе взаимодействия программ.
Какая же архитектура лучше?
Если PowerShell в новой консоли все равно будет перенаправлять объекты, а не текст, то особой разницы в прямоугольничке не будет…
Опечатка в тексте. Символ «A» представляется кодом 0x41, а не 0x40.
По поводу 24-х битного цвета в разных консолях и консольных программах рекомендую посмотреть обзорный GIST gist.github.com/XVilka/8346728
не перепутаны ли на картинке «Архитектура терминала и командной строки» в левой ее части input/output buffer?
Вот сделали новый powershell вместо cmd, а с кодировками 866 и 1251 все тот же ужас.
захочешь простого Enter-PSSession
а уж про Get-WinEvent вообще молчу
захочешь простого 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>
[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')
не обойтись.
[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('utf-8')
не обойтись.
указание кодировок забавно работает
а не работает из под пользователя
поменялась локаль приложения, почему, зачем, непонятно
пробуем Enter-PSSession
удаленная кодировка по умолчанию или koi8-r или 1251, вообще непонятно, и нельзя ее вот так просто взять и поменять
проверяем локально из под пользователя
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
© Корпорация Майкрософт (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
© Корпорация Майкрософт (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
© Корпорация Майкрософт (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 ещё не было даже в планах, и остался с тех пор практически в неизменном виде.
Но что мешало добавить в Powershell указание кодировки?
Ну ё-моё. В самом PS указание кодировки не нужно — он построен вокруг .Net, где строки — в UTF-16. Проблема не в PS, а в том, что сотни тысяч, если не миллионы, классических экзешников, общающихся с внешним миром через стандартный ввод-вывод, не имеют способа указания кодировки. Они её не могут указать никому — ни PS, ни cmd.exe, ни драйверу файловой системы, если stdout перенаправлен в файл. Они просто открывают stdout и записывают в него поток однобайтовых символов в своей текущей кодировке. В принципе, кодировка может быть и не однобайтовой, и это даже может быть не текст, а двоичные данные. Но стандартного способа сигнализации об этом нет — ни в виндах, ни в *nix. Чтобы решить эту проблему, надо менять не только PS, но и переписывать все экзешники, использующие стандартный ввод-вывод.
Нужно! Вот именно по той причине что он построен вокруг .Net, где строки — в UTF-16.
От других программ он получает поток байт, который преобразует в последовательность строк в UTF-16. Вот на этом этапе и нужен механизм указания кодировки.
От других программ он получает поток байт, который преобразует в последовательность строк в UTF-16. Вот на этом этапе и нужен механизм указания кодировки.
И как может выглядеть этот «механизм указания кодировки», если другие программы эту информацию не выдают ни в каком виде?
А, только сейчас дошло — вы имеете в виду указание кодировки руками? Это делается, правда, не сильно удобно.
Расскажите сразу уж, как.
Вот, например, был пост здесь же на Хабре: habr.com/post/321076
Сам, правда, всё это не проверял.
Сам, правда, всё это не проверял.
Так много слов, чтобы объяснить, как можно в виндовой консоли напечатать эмодзи котика-ниндзя?
Сегодня (середина 2018 года) WSL запускает большинство двоичных файлов Linux, программы, компиляторы, компоновщики, отладчикии т.д. Многие разработчики, IT-специалисты, инженеры DevOps и многие другие, кому необходимо запускать или создавать инструменты, приложения, службы Linux и т. д., получили резкое повышение производительности и возможность запускать свои любимые инструменты Linux вместе с любимыми инструментами для Windows на одном компьютере, без загрузки двух операционных систем.
Я всегда с пренебрежением относился к Windows, про Билл Гейтса говорил, что он достоин Нобелевской премии за просвящение в области IT, и страшных кар за то, что беспрецендентное насаждение Windows в нашей стране, вернее в госорганах.
Но после того как я попробал WSL, я сказал, что Билл Гейтс, его команда достойны уважения.
недоразвитость консоли в win10 помоему напрямую растет изза ограниченности Console API или закрытости драйвера консоли. в частности если бы этот API позволял приложению (а не только kernel драйверу) получать иформацию что порожденное приложение рисует небыло бы проблем сторонним разработчикам писать свои консоли и расширения. но сейчас там одни костыли и попытка перехватить нужную информацию через dll injection (смотрим ConEmu), тормозит и глючит. столько воды в статье налито, а побольшому счету надо драйвер консоли в системе сделать открытым и создать экосистему для сторонних расширений, имхо.
недоразвитость консоли в win растет из-за драконовских требований прямой и обратной совместимости: консоль является одной из главных подсистем ОС, и написаны тысячи и тысячи консольных приложений, которые должны работать в консоли — иначе кому нужна консоль с двумя с половиной приложениями?
таким образом, мы либо творим чудеса и сохраняем совместимость, улучшая консоль, либо переписываем все приложения, адаптируя к улучшениям консоли.
таким образом, хоть изначально подход windows console лучше (структура более целостна, чем поток), но подход *nix "всё есть файл"(а точнее, символьный поток) позволяет обогащать возможности при сохранении совместимости ("простое лучше сложного") и взаимодействовать совершенно разным стстемам и программам.
что значит, что открытие ядра не решит проблему.
и подтверждение тому — куча сторонних разработок типа ConEmu, которые все равно глючат и тормозят.
обратная совместимость не мешает дать API разработчикам чтобы перехватить все операции с консолью. но такого API нет, полная информация доступна только драйверу и он закрыт, вот и делают в ConEmu и им подобным перехват работы с консолью через dll injection что сложно, глючит. тормозит ConEmu так как ему приходится через поллинг сканировать консоль на изменения…
в *nix в этом плане все конечно лучше, но дело не только в «все устройства — файл» а именно в открытой имплементации. пока api фактически не предусматривает возможность замены драйвера консоли на свою имплементацию — все равно файл или 101 функция из dll.
в *nix в этом плане все конечно лучше, но дело не только в «все устройства — файл» а именно в открытой имплементации. пока api фактически не предусматривает возможность замены драйвера консоли на свою имплементацию — все равно файл или 101 функция из dll.
Допустим, сделают они API для собственной реализации Console Host, но им воспользуется 2.5 проекта. Но затрат — море (документирование, поддержка обратной совместимости). ИМХО, это экономически невыгодно. Куча людей в MS будет работать не на нужды тысяч разработчиков, как с обычно бывает с API, а на эти 2.5 проекта.
Не видя код трудно сказать как тяжело его расширить. Но в статье упоминается что под консоль выделена команда, допустим 5-10 человек и наверняка с американскими зарплатами. Вон пишут пространные статьи о том как «корабли бороздят» и рефакторят ради рефакторинга (гы). Напишут ли они хорошую консоль — неизвестно, но миллион и больше бюджет за год съедят точно. :)
С моей точки зрения им надо создать вход в систему для сторонних разработчиков в первую очередь а не пытатся строить звездолет. Покрайней мере надеюсь что они новую консоль отправят в свободное плаванье опен-сурса, и документация тогда кстати говоря ненужна (как пример — msbuild задокументирован формально а по существу чтобы что то понять надо открывать код, блоги форумы и так далее).
С моей точки зрения им надо создать вход в систему для сторонних разработчиков в первую очередь а не пытатся строить звездолет. Покрайней мере надеюсь что они новую консоль отправят в свободное плаванье опен-сурса, и документация тогда кстати говоря ненужна (как пример — msbuild задокументирован формально а по существу чтобы что то понять надо открывать код, блоги форумы и так далее).
Ради юниксовых команд перейти на Win 10?! А почему не на Wine?
НЛО прилетело и опубликовало эту надпись здесь
Кстати вопрос: вот у меня есть Windows 10 на первом компьютере, и Windows 10 на втором компьютере. Как мне подключиться с одной в другую, не вызывая при этом рабочий стол, а именно с консоли в консоль? Так можно?
Можно взять для этого PsExec
В самом простом виде — на первой машине в cmd выполняем что-то а-ля
psexec \\имя_второй_машины cmdи получаем желаемое.
В PowerShell'е же подобный функционал есть из коробки.
Насколько я помню, есть более «гуманный» способ. в системных компонентах Windows присутствуют Telnet-клиент и Telnet-сервер. Соответственно, на одной машине нужно включить сервер, на другой клиент и подключиться через cmd командой telnet…
не секьюрно
За что минусанули то, если ваш комментарий вводит в заблуждение. Что имеете ввиду под «секьюрностью» (безопасностью)? Telnet при подключении типа Windows-Windows требует авторизации с использованием учетной записи пользователя.
В целях эксперимента давным-давно отправлял e-mail через smtp.yandex.ru, посредством telnet, с авторизацией.
Какие именно претензии к безопасности telnet-протокола?
В целях эксперимента давным-давно отправлял e-mail через smtp.yandex.ru, посредством telnet, с авторизацией.
Какие именно претензии к безопасности telnet-протокола?
Вся информация, включая пароли, передаётся открытым текстом. Следовательно, если кто-то незаметно включится в свитч локальной сети (или при передаче через интернет он где-то находится по пути передачи данных), то всё прочитает.
Предложенный выше psexec разве шифрует логин и пароль? Вариант с Telnet предложен как альтернатива использованию psexec, который также использует УЗ Windows и поднимает там собственную службу для подобных подключений. По сути это и есть полный аналог telnet, только умеет копировать себя на удаленный компьютер и запускаться как служба, если конечно достаточно прав.
psexec работает через smb, который в свою очередь использует ntlm или даже kerberos (если оба компьютера в домене). В любом случае пароль открытым текстом не передается, то есть хотя бы от пассивного прослушивания защита полная.
Спасибо за уточнение. Если имеется ссылка на статью, содержащую информацию о внутреннем устройстве данной утилиты, то буду благодарен.
www.itprotoday.com/management-mobility/psexec, последние два параграфа
Кстати, telnet тоже можно использовать с Kerberos. Шифрования трафика, правда, не будет, но пароль в cleartext исчезнет.
Самые прямые, там нет никакого шифрования, любой хацкер с WireShark/tcpdump посредине и у него все данные учётной записи и введённые команды.
Telnet передаёт все данные в виде открытого текста (в т.ч. и пару логин-пароль при авторизации) без какого бы то ни было шифрования.
Подключем шифрованный VPN между двумя машинами и имеем шифрованный канал.
ТАк что секурность вопрос организации, а не отдельного приложения.
ТАк что секурность вопрос организации, а не отдельного приложения.
И, внезапно, любые дырявые браузеры становятся безопасными, т.к. нечего по непонятным сайтам шастать, всё это вопрос организации, оказывается.
И тогда всё успешно прослушивает владелец VPN-сервера. Хорошо, если владельцем является доверенный админ, но всё ж проще взять обычный SSH, в котором все проблемы безопасности давно решены и VPN не нужен
Я никого не минусовал. Ну и минус к комментарию, это не «минусанули».
НЛО прилетело и опубликовало эту надпись здесь
Вопрос на ту же тему: можно ли как-то из консоли запущенной на одной Windows 10 подключиться к консоли на другой Windows 10, в которой уже запущено некое консольное же приложение?
Иными словами, есть ли какой-нибудь аналог GNU Screen под Windows?
а теперь запустите в сессии PsExec например FAR или Vim…
В Windows 10 уже завезли OpenSSH (клиент вроде бы предустановлен, сервер нужно включить в компонентах и настроить, сам не пробовал)
Там огромные проблемы с безопасностью, именно поэтому его не берут в upstream, хоть бравые парни из MS собирались всё написать за пару месяцев и закинуть в upstream до конца 2016 года.
Разработчики никогда не слышали про современные наилучшие практики безопасности, что для базового инструмента обеспечения безопасности довольно странно.
Сам по себе продукт официально является Beta-версией и тянет за собой, насколько я помню, установку сырых PowerShell Core и .Net Core, которые ещё и будут сосуществовать у вас на компьютере с нормальными PowerShell и .NET.
Потестировать — можно, рекомендовать это для нормальной работы я бы не стал.
Разработчики никогда не слышали про современные наилучшие практики безопасности, что для базового инструмента обеспечения безопасности довольно странно.
Сам по себе продукт официально является Beta-версией и тянет за собой, насколько я помню, установку сырых PowerShell Core и .Net Core, которые ещё и будут сосуществовать у вас на компьютере с нормальными PowerShell и .NET.
Потестировать — можно, рекомендовать это для нормальной работы я бы не стал.
НЛО прилетело и опубликовало эту надпись здесь
Читал и вспоминал, да что там вспоминал — чувствовал боль программирования под win32.
MSDN с его табличками какие API поддерживаются в каких версиях W, скупые советы как обходитьбаги фичи конкретной версии W.
MSDN с его табличками какие API поддерживаются в каких версиях W, скупые советы как обходить
всего лишь надо добавить префикс U
Действительно, не то что на Linux, где изменение LibC ломает половину софта.
Ну так кто мешает держать несколько libC для разных версий софта? Или вообще вариант snap/flatpak, когда софт сам тащит с собой нужную версию.
Эта проблема не так актуальна — дистрибутивы собираются под конкретные версии, да и пересобрать самому вообще не проблема — в мире unix динамические бинари никто не переносит между разными дистрибутивами.
А также есть развитая система автоконфигурирования (autoconf/automake).
А также есть развитая система автоконфигурирования (autoconf/automake).
Напомнило добрые времена BBS и Fidonet
рука-нога
Мне всегда казалось, что проблема в подходе к написанию системы.
В Linux консоль первична, «всё есть файл», и все наработки опираются на консоль.
В Windows консоль — не основа системы, а приделанный сбоку функционал. Не знаю как сейчас, но раньше в Windows некоторые вещи вообще нельзя было сделать через консоль — только через графический интерфейс.
Кстати, в статье упоминаются проблемы с парсингом вывода консольных утилит в никсах. Неужели на каком-то этапе развития нельзя было перейти к выводу данных в xml? Или переходу от «всё есть файл» к «всё есть файл или директория», который позволил бы получать конкретные значения и использовать, так сказать, «объектный подход»?
В 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ка, хотя и работает, вешает комп намертво при обновлениях (а иногда и просто так), поэтому работать невозможно.
Тем не менее, и Debian, и NixOS позволяют одновременно слушать музыку, компилить проект, и виртуалке тестить клиент под windows 7, а 10ка, хотя и работает, вешает комп намертво при обновлениях (а иногда и просто так), поэтому работать невозможно.
Чисто в рамках «помочь» — комплект из одной плашки ddr4 16Gb + материнка Asus + Ryzen 2600 + NVMe M.2 Samsung сейчас в тысяч 40 кажется укладывается.
Я понимаю, что у кого-то может быть такой целая зарплата, у кого-то ипотека/долги, есть семья. Но все-таки это не такая неподъемная сумма (для IT), чтобы прям страдать — верю, что на сейчас у вас есть возможность сделать так, чтобы еще много лет более не страдать.
Серьезно, я как познакомился с М.2 дисками, так понял, что классические SSD прошлый век, близко не стоят к новому поколению.
P.S. Забавно, что я свою платформу чуть позже вас сменил. А исходный у меня был точно так же чуть моложе — 2008-го, на 775 сокете с Core Quad… хороший был комп, надежный боевой товарищ для своего времени.
Я понимаю, что у кого-то может быть такой целая зарплата, у кого-то ипотека/долги, есть семья. Но все-таки это не такая неподъемная сумма (для 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, но всё равно удивительное совпадение!
;)
Ну, обсуждение велось летом (вот это же время летит — аж депрессия накатывает). А почти такой стац собирался в самом конце весны / начале лета. Сейчас цены опять скакнули (а на подходе «радости» «НДС 20%»/«снижение беспошлинного лимита» и прочее) :(
P.S. Хм, интересная видимо собака.
Правда в 40000 не уложился, получилось 50000, но всё равно удивительное совпадение!
Ну, обсуждение велось летом (вот это же время летит — аж депрессия накатывает). А почти такой стац собирался в самом конце весны / начале лета. Сейчас цены опять скакнули (а на подходе «радости» «НДС 20%»/«снижение беспошлинного лимита» и прочее) :(
P.S. Хм, интересная видимо собака.
Проблемы с парсингом текста — меньшее из зол. Unix-идеология подталкивает разработчиков выбирать такой формат вывода, чтобы он был удобным как для чтения человеком так и для парсинга примитивными инструментами. Кому сильно нужно отдают в данные структурированном виде или используют perl, python и т.п. Директории конечно есть, куда без ник.
XML младенец, по сравнению с консолью. Да и XML мягко говоря спасение, существуют более эффективные форматы: json, yaml, bson и тп. В классической unix консоли идет упор на читабельность и простоту.
Все равно, что бинарный registry и текстовые конфиги.
Все равно, что бинарный registry и текстовые конфиги.
Кстати, а кто может объяснить причину того, что частенько вывод в консоль в винде замирает, фризя при этом само приложение и пока не нажмешь enter программа в терминале просто висит?
Здесь опять я намерен прервать рассказ — вернёмся к этой теме в следующей статье.Узнаю стиль поддержки майкрософт:
— Как это сделать?
— Никак, мы обязательно вернемся к этому в следующий раз. Оставайтесь с нами!
А можно из PowerShell просто подключиться через SSH? Как в нормальной линуксоид консоли. Типа
ssh -v -p52000 user@server.ipВсегда можно было и из cmd, если ssh клиент лежит в %PATH%
Начиная с Windows 10 1709, в дополнительных компонентах можно включить клиент OpenSSH и использовать его в cmd и PowerShell.
PS C:\Users\dr\Desktop> ssh -V
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
ssh можно найти рядом с git если у вас стоит Git for Windows
Спасибо за статью! Много нового узнал!
P.S. На правах личного мнения. Без холивара! Мне кажется, что WSL — это извращенство высшей степени, т.к. windows ушла далеко от POSIX, да и блочные устройства — не нативное для ntfs, а значит, что всякие pipe и sock тоже будут работать с большим оверхедом. Поправьте, если неправ.
P.S. На правах личного мнения. Без холивара! Мне кажется, что WSL — это извращенство высшей степени, т.к. windows ушла далеко от POSIX, да и блочные устройства — не нативное для 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 запилили какое-то автоматическое объединение окон приложений во вкладки. Возможно, это оно.
Это системные вкладки, только они еще не релизнулись. insider.windows.com/ru-ru/articles/introducing-sets
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тяжкое наследие прошлого. Проблемы командной строки Windows