Comments 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 ещё было?
UFO just landed and posted this here
Лет 15-20 назад, читал замечательный рассказ «последний пользователь» (как-то так, прошу прощение за мой склероз) Канва истории — на планете все сидят на одной ОС, но вот человек купил себе ПК, юзает его (поф как, хоть в опкодах) но не хочет покупать себе всепланетную ОСь, его и так все устраивает, но это не устраивает акционеров корпорации добра, и к (тому человеку) прислали рекламного агента — он (рекл агент) стоя в дверях аж плачет — вы единственный у кого нет нашей замечательной программы! — а мне не нужно. -вам не нравится наша ОСь? — нравится, — но почему? — не хочу. (тут уместен кадр из «собачьего сердца» с продажей профессору Преображенскому журналов) — вы против прогресса? — непротив, — но почему? корпорация добра уполномочила подарить вам нашу программу, вы единственный, кто ей не пользуется! — не хочу и все.
У меня вот с линуксом та же история. Не хочу и всё тут, все вокруг бегают, кричат, восхищаются, а мне не нравится. Вот фряха симпатичная, всё чего нельзя сделать под виндой, можно сделать там, но всем нужен проклятый линукс. Точнее каждому нужен какой-то свой, особенный, из сотен вариантов линукса. И это вгоняет меня в уныние.
«Сделайте систему, которой сможет пользоваться даже идиот — и только идиот захочет ей пользоваться».
Есть некая грань популярности, после которой следует сползание софта в попсу — и вроде всем понятный, и удобный, но с этого момента обычно следует внедрение рюшечек и эмотиконов взамен развития в сторону функциональности.
Возможно, относительно малая популярность — не так уж и плохо?
Есть некая грань популярности, после которой следует сползание софта в попсу — и вроде всем понятный, и удобный, но с этого момента обычно следует внедрение рюшечек и эмотиконов взамен развития в сторону функциональности.
Возможно, относительно малая популярность — не так уж и плохо?
DOS, Windows, CP/M, OS/2, Solaris...
16-битный недоюникод не поддерживающий стандарт Unicode, альтернативная система вывода (отличная от всего остального мира), слеши в путях не в ту сторону, аргументы командной строки, которые приложение должно парсить само…
Прям комок боли. Осталось приклеить стикер «Windows», и готово.
Прям комок боли. Осталось приклеить стикер «Windows», и готово.
Слеши можно писать правильньіе, повершелл автоматом заменяет на свои.
слеши в путяхХорошо, если слеши. В японской и корейской Windows свои знаки.
Проблема с парсением аргументов полностью решена в PS. В классических консольных приложениях же, насколько я в курсе, ситуация не сильно отличается *nix-мира: частично решается при помощи стандартных RTL. Если писать на C, то аргументы будут вам переданы в main в виде (argc, argv) — правда, степень стандартизации их синтаксиса всё равно гораздо ниже, чем в PS.
UFO just landed and posted this here
А при чём тут linux'оиды? PDP/11 был задолго до появления Windows 1.0 и задолго по появления Linux.
Ну как бы если бы кто-то настаивал, что в конце предложения надо ставить значок "ō" вместо точки. Все до него использовали ".", все кроме него используют "." и только он утверждает, что писать надо иначе ō
Ну как бы если бы кто-то настаивал, что в конце предложения надо ставить значок "ō" вместо точки. Все до него использовали ".", все кроме него используют "." и только он утверждает, что писать надо иначе ō
UFO just landed and posted this here
Ультимативное оправдание для любой фигни. «тогда так надо было, и тридцать лет спустя мы должны это продолжать». Причины и оправдания могут быть любые — на выходе-то эргономика использования сейчас.
Комок легаси-совместимости с мёртвыми системами со стикером Windows. Такое определение лучше?
Комок легаси-совместимости с мёртвыми системами со стикером Windows. Такое определение лучше?
UFO just landed and posted this here
Так никто и не меняет. setup.exe для windows 95 всё ещё существует. У всех остальных есть запросы на перемены.
UFO just landed and posted this here
Вы⍀совершенно⍀правыāКаждый⍀может⍀использовать⍀такие⍀знаки⍀препинания°⍀какие⍀хочетāНикто⍀не⍀может⍀решать°⍀какие⍀знаки⍀! правильнее¡ā
Windows долго крутилась в своем монастыре со своими уставами, в результате полностью потеряла мобильный рынок и с трудом удерживает жалкий процент на серверном.
Сейчас до MS начало доходить, и они стали потихоньку внедрять стандарты, существующие уже несколько ДЕСЯТКОВ лет.
Сейчас до MS начало доходить, и они стали потихоньку внедрять стандарты, существующие уже несколько ДЕСЯТКОВ лет.
UFO just landed and posted this here
UFO just landed and posted this here
Эм… Это про какую часть linux'а вы говорите? Вы случайно linux с mc не путаете?
И не всем программам подходит этот странный уговор, что регистровых клавиш как бы не существует на клавиатуре.
Не путайте программы и протоколы.
Попробуйте реальную консоль линукса, а не эмуляции.
Или расскажите, как хорошо работают все хоткеи в винде через rdp, особенно если не фулл скрин?
UFO just landed and posted this here
Реальной консолью он называет то, что видно по 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?
UFO just landed and posted this here
Кстати вопрос: вот у меня есть 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 не нужен
Я никого не минусовал. Ну и минус к комментарию, это не «минусанули».
UFO just landed and posted this here
Вопрос на ту же тему: можно ли как-то из консоли запущенной на одной 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.
Потестировать — можно, рекомендовать это для нормальной работы я бы не стал.
UFO just landed and posted this here
Читал и вспоминал, да что там вспоминал — чувствовал боль программирования под 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
Sign up to leave a comment.
Тяжкое наследие прошлого. Проблемы командной строки Windows