Terminal: Windows 10 1809 / 19H1 / 20H1 нарушает настройки консоли Powershell. Продолжает открываться с помощью растровых шрифтов.

У меня то же самое происходит только при использовании шрифта Consolas. Если я использую что-то еще - Courier New, Lucida Console и т. Д. - настройки сохраняются.

@ 50Wliu Я могу подтвердить такое поведение. Консоли сбрасываются на растровый шрифт. Консоль Lucida остается консолью Lucida.

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

Я думал, что раньше у нас были проблемы с отслеживанием этого, но я не могу их найти. @bitcrazed , ты помнишь, где они были? Или это была внутренняя переписка с

Может кто-нибудь предоставить точное воспроизведение? Например, какой шрифт вы устанавливаете для ярлыка. Какой шрифт установлен?

• Win-R и запустите powershell .
• Начинается с растрового шрифта.
• Зайдите в настройки и установите шрифт Consolas. Щелкните ОК.
• Консолас применяется.
• Закройте Powershell.
• Снова откройте PowerShell, как раньше.
• Шрифт снова растровый.
• Зайдите в настройки по умолчанию и установите шрифт Consolas. Щелкните ОК.
• Закройте Powershell.
• Снова откройте PowerShell, как раньше.
• Шрифт снова растровый.

Я не думаю, что это была вина даже Powershell. У меня где-то есть заметка о том, что одна из самых последних .NET Framework (4.7something) внезапно решает использовать 65001 в качестве кодовой страницы по умолчанию для всех приложений, и когда она переключается с другими инструментами и кодовыми страницами при их запуске и выходим, пересчитываем шрифт.

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

Я не могу воспроизвести это здесь. И Windows PowerShell, и Powershell запускаются с установленным мной шрифтом.

@Borkason Вы пробовали concfg clean
https://github.com/lukesampson/concfg

@borakson - какой языковой стандарт настроен на использование вашей Windows?

@bitcrazed Я не @Borkason, но, поскольку у меня

Мой язык отображения - испанский (Испания), как и мой региональный формат. Язык для программ, которые не поддерживают Unicode, - английский (США), и у меня установлен флажок бета-версии для UTF-8 Unicode. (Надеюсь, это то, что вы ищете ... дайте мне знать, если вы просили что-то еще)

@bitcrazed немецкий. И я обновился с 1803. Забыл это иметь в виду.

@doctordns какой шрифт?

@doctordns какой шрифт?

Я использую Lucida Console (18 pt). Но я тестировал другие, и они тоже работают после перезапуска Windows PowerShell.

У меня то же самое происходит только при использовании шрифта Consolas. Если я использую что-то еще - Courier New, Lucida Console и т. Д. - настройки сохраняются.

Вероятно, это было исправлено недавней работой @lzybkr : https://github.com/lzybkr/PSReadLine/issues/542

@Borkason и @doctordns - не могли бы вы подтвердить и закрыть, если исправлено?

Благодарю.

@bitcrazed похоже, что проблема, на которую вы ссылаетесь, была исправлена ​​еще в 2017 году и, насколько я могу судить, включена в версию PSReadLine, с которой поставляется 1809. Кроме того, эта проблема все еще возникает у меня, начиная с сборки Windows Insiders 18277.

@bitcrazed Это на год старше версии 1809 года. Я бы не назвал это «недавним».

И для меня ничего не изменилось. У меня Windows 10 сборка 17763.107

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17763.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Но, как уже сказал @ 50Wliu , это даже не исправлено в текущем превью.

Вот ссылка на Отзыв: https://aka.ms/AA37kk1

@bitcrazed связана с проблемой, вызвавшей проблему.

Исправление в этом PR: https://github.com/lzybkr/PSReadLine/pull/771

Справедливо. Известно ли, с какой сборкой будет выпущено исправление?

Я постараюсь выпустить еще одну бета-версию PowerShell Gallery до конца года, но я ничего не знаю о Windows (я не работаю с Windows).

@ SteveL-MSFT владеет битами, которые поставляются в Windows, так что, возможно, он сможет прокомментировать.

Имя Значение
---- -----
PS Версия 5.1.17763.134
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0 ...}
Версия сборки 10.0.17763.134
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolВерсия 2.3
Сериализация Версия 1.1.0.1

то же самое здесь ... готовы переустановить окна, ДЕЙСТВИТЕЛЬНО больно!

Эта проблема кажется ссылками на шрифты. У меня проблема в Powershell с окнами (cmd и ядро ​​Powershell не имеют этой проблемы), когда я устанавливаю шрифт как «Консоль», но когда я меняю шрифт на «Sarasa Mono SC», все работает отлично. Я использую Sarasa Mono SC для отображения символа UTF-8, в Windows 10 нет шрифта по умолчанию, который может отображать достаточно символов UTF-8.

Тоже самое. И мой Surface, и настольный ПК.

Как ни странно, я думаю, что испытываю ту же проблему, но по-другому. Каждый раз, когда открывается подпроцесс для запуска powershell.exe, шрифт консоли меняется на растровый из Consolas.

Пример 1: У меня запущен vim (WSL), и он запускает подкоманду powershell для получения системного буфера обмена. Каждый раз, когда я запускаю эту команду, она сбрасывает шрифт консоли на растровые.

Пример 2: У меня есть сценарий оболочки, который запускает powershell в качестве подпроцесса для получения системных серверов имен. С консолью происходит то же самое - переход на растровые шрифты. На консоль ничего не выводится. Все происходит в подпроцессе.

Действительно странно то, что если я запускаю PowerShell вручную из консоли (WSL), то все в порядке, и шрифт не меняется.

@bitcrazed , @ SteveL-MSFT, @lzybkr : У меня есть хорошее минимальное воспроизведение. Это начало происходить сразу после того, как я обновил машину до Windows 1809. У меня был установлен шрифт и CP консоли, как показано ниже, на Consolas и 65001 соответственно, и все работало нормально. Я работаю с файлами UTF-8, поэтому CP 65001 был мне необходим. Моя локаль - обычный старый en-US, английский язык Windows 10 x64 Pro, а OEM CP по умолчанию 437.

1. Установите следующие ключи реестра (сохранить как .reg и импортировать). По какой-то причине важно изменить FontFamily, поскольку значение по умолчанию может быть другим, и шрифт не будет применяться.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Console]
"FaceName"="Consolas"
"FontFamily"=dword:00000036
"FontSize"=dword:000f0000
"FontWeight"=dword:00000190
"CodePage"=dword:0000fde9

1. Win + R cmd.exe ENTER . Консоль запускается с правильным шрифтом и кодовой страницей. Введите chcp ; он печатает 65001 (если нет, запустите chcp 65001 ).
2. в консоли введите powershell -noprof ('-noprof', чтобы подтвердить, что проблема не связана ни с чем, что я загружаю в свой профиль).

При запуске PowerShell шрифт консоли немедленно меняется на растровый, а размер окна изменяется в соответствии с его размером. Выбран растровый шрифт Terminal, и в нем даже нет символов WGL4 (без кириллицы или греческого языка). Так что это определенно ошибка.

Такое поведение воспроизводится даже при запуске неинтерактивной команды, поэтому весьма сомнительно, что ошибка связана с PSReadLine:

powershell -noprof -nonint -command "echo foo"

Кроме того, шрифт консоли изменяется аналогично (по сути, консоль открывается с растровым шрифтом), если PowerShell запускается с помощью ярлыка, из диалогового окна Win + R или двойным щелчком мыши в проводнике.

Также есть минусы. Шрифт не меняется, если:

• Я запускаю chcp 437 перед вызовом powershell из cmd.
• Для шрифта консоли в реестре установлено значение «Lucida Console» (все остальное остается таким же, как указано выше). О том, что этот шрифт является чем-то «особенным», уже отмечалось в комментариях к этому тикету.

Общей темой в комментариях к этому выпуску, я полагаю, была неамериканская, европейская локаль (были упомянуты немецкий и испанский языки). Итак, я попробовал следующее:

1. Запустите cmd.exe
2. Установите кодовую страницу консоли с chcp NNN (см. Ниже):
3. Запустите powershell -noprof .

• При NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - без изменения шрифта
• При NNN = 65001, 858 и не-WGL4 иврит 862, арабский 864 - шрифт меняется.

Что отличает CP 858 от других? Думаю, это может быть ключом. Название CP - "OEM Multilingual Latin 1 + Euro symbol".

Также примечательно, что chcp 1255 и chcp 1266 (иврит и арабский) меняют шрифт на "Courier New" даже в cmd.exe . Значит, PowerShell может быть только в какой-то степени более уязвимым, а не главным виновником?

Обязательная информация о версии:

C:\Users\kkm> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17763.134
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.134
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

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

@ kkm000 Это было исправлено в PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771), но отсутствует в сборке Windows, которую вы используете, хотя исправление было проверено в более новой сборке Windows. Я считаю, что в новейшей общедоступной бета-версии PSReadLine есть исправление, поэтому вы можете установить его в Windows PowerShell, используя:

install-module psreadline -AllowPrerelease -Repository PSGallery -Force
# restart PowerShell to load the new one

Если он жалуется, что -AllowPrerelease не найден, вам придется обновить PowerShellGet:

install-module powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber
# restart PowerShell to load the new one

хотя исправление было проверено в более новой сборке Windows.

Означает ли это, что исправление появится в будущем (19H1) выпуске для инсайдеров?

@ 50Wliu да

@ SteveL-MSFT У меня такая же версия, как у @ kkm000 , я запускал вам команды и не работает для меня, я что-то пропустил?

@ SteveL-MSFT Мне очень досадно, что это не может поставляться с обычным Центром обновления Windows. Если Microsoft ломает что - то с обновлением, это их ответственность , чтобы исправить это с обновлением , а не откладывать его в течение более шести месяцев и планируют отправить его в следующей версии Windows , или есть люди прыгают через обручи , чтобы получить исправление от пре- релизный репозиторий (который работает даже не у всех).

итак .... мне приходилось запускать эту команду более одного раза

установить модуль powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber

с Powershell, запущенным от имени администратора, taskmgr, чтобы убить Powershell, а затем сделать это снова, поскольку он не удался два или три раза. И… похоже, он работает! Настроенные параметры отображения в моем $ PROFILE теперь ведут себя так же, как и до обновления.

Это только начало происходить со мной после обновления до последней сборки 1809 17763.292 из предыдущего накопительного обновления 1809 . Я выполнил инструкции по установке нового PSReadLine, и, похоже, он там:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
я имею

PSVersion 5.1.17763.134

Шрифт Consolas заменен на растровые.

ОБНОВИТЬ

это кажется нестабильным исправлением. Теперь после перезагрузки фикс держится / работает вне зависимости от уровня запуска.

Интересное поведение я сейчас наблюдаю. После запуска исправления на моем ноутбуке
Имя Значение
---- -----
PS Версия 5.1.17763.134
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0 ...}
Версия сборки 10.0.17763.134
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolВерсия 2.3
Сериализация Версия 1.1.0.1

при запуске PS в пользовательском режиме исправление в порядке; при запуске PS от имени администратора исправить не получается.

У меня не работает даже в пользовательском режиме.

@ SteveL-MSFT, похоже, это исправление у меня не работает. Кроме того, похоже, что Install-Module ничего не изменил. У меня уже есть довольно последний PowerShellGet ( -AllowPrerelease безусловно, работает; мои привязки клавиш зависят от недавнего PSReadLine). Я изначально установил PSReadLine несколько месяцев назад (до обновления Windows!), Поэтому я ожидал, что получу обновление сегодня с вашей предложенной командой, но я не знаю, как проверить, действительно ли что-то было изменено. Не могли бы вы помочь? Я взял версию PSReadLine перед попыткой обновления:

C:\WINDOWS\system32> date

Saturday, February 2, 2019 13:46:02

C:\WINDOWS\system32> Get-Module PSReadline | fl Version

Version : 2.0.0

C:\WINDOWS\system32> Get-Module PSReadline | fl *

LogPipelineExecutionDetails : False
Name                        : PSReadline
Path                        : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.psm1
ImplementingAssembly        :
Definition                  : function PSConsoleHostReadLine
                              {
                                  Microsoft.PowerShell.Core\Set-StrictMode -Off
                                  [Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
                              }

Description                 : Great command line editing in the PowerShell console host
Guid                        : 5714753b-2afd-4492-a5fd-01d9e2cff8b5
HelpInfoUri                 : https://go.microsoft.com/fwlink/?LinkId=528806
ModuleBase                  : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0
PrivateData                 : {PSData}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    : https://www.powershellgallery.com/api/v2/
Version                     : 2.0.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0.0
CompanyName                 : Microsoft Corporation
Copyright                   : (c) Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      : 4.6.1
ExportedFunctions           : {[PSConsoleHostReadLine, PSConsoleHostReadLine]}
Prefix                      :
ExportedCmdlets             : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
ExportedCommands            : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {Microsoft.PowerShell.PSReadLine}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : PSReadLine.psm1
ExportedVariables           : {}
ExportedAliases             : {}
ExportedWorkflows           : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.format.ps1xml}
ExportedTypeFiles           : {}

Затем я обновился, как вы предложили:

C:\WINDOWS\system32> install-module psreadline -AllowPrerelease -Repository PSGallery -Force
C:\WINDOWS\system32> exit

Install-Module некоторое время перемешивался, а вверху экрана отображалась полоса прогресса с полосой «o». Я не верю, что это что-то значит, но повторение Install-Module также приводит к тому, что на короткое время появляется индикатор выполнения. Но новая консоль по-прежнему страдает изначальной проблемой. Также я не вижу здесь никаких изменений, может быть, вы что-то заметили? Я, конечно, могу посмотреть версии файлов и т. Д., Которые у меня есть, только я не знаю, что искать.

Это тоже ничего не дало:

C:\WINDOWS\system32> Update-Module PSReadLine -AllowPrerelease
C:\WINDOWS\system32>

В новой консоли новый (?) PSReadLine выглядит так же:

C:\WINDOWS\system32> Get-Module PSReadline | fl *

LogPipelineExecutionDetails : False
Name                        : PSReadline
Path                        : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.psm1
ImplementingAssembly        :
Definition                  : function PSConsoleHostReadLine
                              {
                                  Microsoft.PowerShell.Core\Set-StrictMode -Off
                                  [Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
                              }

Description                 : Great command line editing in the PowerShell console host
Guid                        : 5714753b-2afd-4492-a5fd-01d9e2cff8b5
HelpInfoUri                 : https://go.microsoft.com/fwlink/?LinkId=528806
ModuleBase                  : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0
PrivateData                 : {PSData}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    : https://www.powershellgallery.com/api/v2/
Version                     : 2.0.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0.0
CompanyName                 : Microsoft Corporation
Copyright                   : (c) Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      : 4.6.1
ExportedFunctions           : {[PSConsoleHostReadLine, PSConsoleHostReadLine]}
Prefix                      :
ExportedCmdlets             : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
ExportedCommands            : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {Microsoft.PowerShell.PSReadLine}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : PSReadLine.psm1
ExportedVariables           : {}
ExportedAliases             : {}
ExportedWorkflows           : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.format.ps1xml}
ExportedTypeFiles           : {}

Кроме того, из-за комментариев @ mjoyce6500 и @wigster выше, я проверил пользовательскую (не админскую) консоль, и она также показывает ошибку, как и раньше.

Пожалуйста, буду благодарен за любую помощь / мысли, которыми вы могли бы поделиться!

@ SteveL-MSFT, @lzybkr , не думаю, что в PSGallery есть обновление. Последняя бета-версия была опубликована за месяц до слияния проблемы lzybkr / PSReadLine # 771:

C:\WINDOWS\system32> Find-Module PSReadline -Repository PSGallery -AllVersions -AllowPrerelease | ft name,ver*,pub*

Name       Version     PublishedDate
----       -------     -------------
PSReadLine 2.0.0-beta3 2018-09-04 21:59:13
PSReadLine 2.0.0-beta2 2018-06-04 20:28:42
PSReadLine 2.0.0-beta1 2017-12-06 07:22:16
PSReadLine 1.2         2016-01-25 20:43:22
PSReadLine 1.0.0.13    2015-02-18 00:28:18
PSReadLine 1.0.0.12    2014-08-26 19:04:26
PSReadLine 1.0.0.11    2014-06-13 21:15:30
PSReadLine 1.0.0.10    2014-06-13 02:21:13
PSReadLine 1.0.0.9     2014-06-11 21:20:46
PSReadLine 1.0.0.8     2014-05-07 22:20:52

К сожалению, он больше не включает ReleaseNotes, как это было в beta2. Но время, конечно, исключает такую ​​возможность.

Несвязанное примечание, Автор и Компания, по-видимому, поменялись местами:

C:\WINDOWS\system32> Find-Module PSReadline -req 2.0.0-beta3 -Repository PSGallery -AllowPrerelease | fl author,compan*

Author      : Microsoft Corporation
CompanyName : lzybkr

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

@ mjoyce6500 вы можете дать мне точные шаги

@ SteveL-MSFT, не могли бы вы взглянуть на мой комментарий выше ? Я даже не могу найти обновленную версию PSReadLine в PSGallery, а другие люди сообщают о «смешанных результатах». На данный момент самой высокой доступной версией по-прежнему является PSReadLine 2.0.0-beta3 18-09-04 21:59:13 , опубликованная за месяц до слияния исправления.

Кроме того, как узнать, какую версию я использую? На другом компьютере, где я никогда не пробовал ваше предложение по обновлению, проверив первую строку файла Changes.txt из установленного пакета:

C:\WINDOWS\system32> Get-Module PSReadline | fl version,modulebase

Version    : 2.0.0
ModuleBase : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0

C:\WINDOWS\system32> gc "C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\Changes.txt" | select -first 1
### Version 2.0.0-beta2

Затем Install-Module действительно пытается установить 2.0.0-beta3, подтвердите, запустив без -force :

C:\WINDOWS\system32> install-module psreadline -AllowPrerelease -Repository PSGallery
WARNING: Version '2.0.0-beta2' of module 'PSReadline' is already installed at 'C:\Program
Files\WindowsPowerShell\Modules\PSReadline\2.0.0'. To install version '2.0.0-beta3', run Install-Module and add the -Force parameter, this command will install version '2.0.0-beta3' side-by-side with version '2.0.0-beta2'.

Возможно ли, что я получаю обновление не откуда-то еще?

После обновления Changes.txt имеет заголовок 2.0.0-beta3 в качестве первой строки:

C:\WINDOWS\system32> gc "C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\Changes.txt" | select -first 1
### Version 2.0.0-beta3

И воспроизведение такое же, как и раньше, в админке или нет. Из консоли cmd.exe со шрифтом Consolas:

C:\WINDOWS\system32>chcp 65001
Active code page: 65001

C:\WINDOWS\system32>powershell -noprof -nonint
==== BOOM! font changes ===
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\WINDOWS\system32>

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

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

До сих пор непостижимо, как исправление сработало (по крайней мере частично) для меньшинства людей, учитывая, что оно так и не было выпущено, глядя сквозь эту пару глаз. Сказать, что я сбит с толку, значит ничего не сказать. В настоящее время я думаю, что существует ДВЕ галереи PS, и исправление было опубликовано для одной из них, к которой имеют доступ только несколько человек.

@ kkm000 Существует одна PSGallery, а beta.3 - это последняя опубликованная PSReadLine. Версия PSReadLine 2.0.0, поставляемая с Win10, является форком PSReadLine 2.0.0 с некоторыми более новыми конкретными исправлениями, поэтому в этом смысле она опережает версию, опубликованную в PSGallery.

@ SteveL-MSFT
Я установил beta3 и ничего не решено.
Оба с Windows 1809 и 1903 (сборка 18334.1)

@Borkason исправление, позволяющее не менять шрифт, если не используется растровый шрифт, уже должно быть в этой сборке. Какой шрифт вы используете?

Я использую Консолас. Он переключается обратно после каждого перезапуска PowerShell.

@Borkason, какой язык вы используете? en-US или что-то еще?

de-DE

Теперь это внезапно работает. Взял у меня вроде 10 раз закрытие и открытие powershell, но теперь вроде залипает.

Он снова сломался. Так что, очевидно, он случайно решает снова сломаться или работать. 💢

У меня это случилось с 18334 - совершенно случайно. Больше не повторилось.

Хорошо, разница в том, что когда я запускаю PowerShell через ALT-R, шрифт остается прежним. Когда я запускаю его из меню «Пуск», он сбрасывает шрифт на растровый, даже если я изменил его на consolas в предыдущем сеансе, который я запускал из меню «Пуск».

(И под меню «Пуск» я на самом деле имею в виду, что я нажимаю клавишу Windows на клавиатуре, а затем набираю «powershell» и нажимаю Enter.)

@ SteveL-MSFT - я не публиковал выпуск с исправлением шрифта в галерее PowerShell. Однако исправление доступно в репозитории PSReadLine, поэтому вы можете собрать его самостоятельно или получить сборку из AppVeyor.

@Borkason - Если вы используете Consolas я думаю, вы не должны видеть ошибку шрифта.

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

Если вы используете Consolas я думаю, вы не должны видеть ошибку шрифта.

Тогда эта ошибка не устранена, потому что я использую Consolas, и ярлык тоже.

По-прежнему сложно установить настройки консоли по умолчанию из-за обратной совместимости.

Затем Microsoft должна предоставить скрипт / FixIt-инструмент для тех, кто просто хочет, чтобы их консоль снова работала, независимо от обратной совместимости ...

Я знаю, что консольная команда хочет решить эту проблему, но, по-видимому, это сложная проблема.

По всей видимости. И, очевидно, мучительно сложно поместить чертово полуисправление PowerShell в 1809, не говоря уже о 1903 ...

😠

Я только что обновился до 18342, и проблема, похоже, исправлена ​​(18334 по-прежнему сбрасывается на растровые шрифты каждый раз).

Я все еще согласен с тем, что исправление должно быть перенесено на 1809.

РЕДАКТИРОВАТЬ: проблема неправильной конфигурации при обновлении (см. Https://github.com/Microsoft/console/issues/280#issuecomment-474917761). Ошибка до сих пор не исправлена.

Я только что сделал новую установку 20H1. Проблема все еще существует. 🤣 Это же шутка?

Это можно исправить, установив инструменты Rsat 1809 windows 10.
Вы не можете установить RSAT на компьютерах под управлением домашних или стандартных выпусков Windows.
Вы можете установить RSAT только в выпусках Windows 10 Professional или Enterprise.

Метод 1. Использование добавления функции. Установите инструменты RSAT в Windows 10 версии 1809.

Чтобы установить RSAT Tools в Windows 10 версии 1809, нажмите Пуск. Щелкните Параметры и на странице параметров щелкните Приложения.
На правой панели в разделе Приложения и функции щелкните Управление дополнительными функциями.
Теперь нажмите + Добавить функцию. Подождите, пока будет заполнен список функций.
Прокрутите вниз, пока не увидите функции RSAT.
Теперь выберите любую функцию RSAT, которую вы хотите установить. В этом случае я выбираю RSAT: средство управления групповой политикой.
Щелкните Установить.
Щелкните значок "Назад" и дождитесь установки функции.
Теперь вы должны найти Инструменты управления групповой политикой в ​​разделе Пуск> Инструменты администрирования Windows.

работает ... Установите RSAT Tools в Windows 10 версии 1809 и новее
Автор: Prajwal Desai Последнее обновление: 31 января 2019 г.

Надеюсь это поможет....

@RobRoberson, ты действительно понимаешь, о чем говоришь, верно?

У меня такая же проблема с Windows 1809 17763.316.
zh_Hans_CN с включенной опцией UTF-8.

Решат ли предварительные версии проблему?

Решат ли предварительные версии проблему?

Нет.

Я возвращаю то, что сказал в https://github.com/Microsoft/console/issues/280#issuecomment -465837677. На самом деле произошло то, что все мои языковые настройки были сброшены, что отключило кодовую страницу 65001. Я только что понял это сегодня, снова включил и ... привет растровые шрифты.

@ SteveL-MSFT, этот ваш

Хотел бы исправить это. Очень нравится Consolas для разработки под Windows.

Использование внутреннего выпуска Microsoft 1903 может подтвердить, что эта ошибка все еще существует для Consolas и UFT8. Шрифт Lucida Console работает и будет моим обходным решением

Мы работаем над новым обновлением для PSReadLine, а потом посмотрим, как добавить его в Windows

В pwsh 6.2.0 эта проблема, казалось, была решена, но она вернулась после того, как я использовал msbuild 2017 для сборки чего-либо (версия 2015 года была в порядке). Я не уверен, где именно это происходит, потому что это из node-gyp , но если собственные модули необходимо (пере) собрать, моя консоль вернется к растровым шрифтам.

К счастью, мне больше не нужно сбрасывать шрифты каждый раз, когда я открываю терминал, только при запуске node-gyp.

Была опубликована PSReadLine 2.0.0-beta4, которая должна решить многие проблемы (хотя в ней есть несколько новых). https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@ SteveL-MSFT 2.0.0-beta4 не исправил эту ошибку.

Я использую обычный терминал CMD с git bash.exe + phpunit = та же проблема. Появляется через несколько секунд после начала работы скрипта.
Не уверен, что причина в PowerShell ...

@ SteveL-MSFT 2.0.0-beta4 тоже не исправляет ошибку.

@sebgod Спасибо за подсказку, я перешел с Consolas 16 на Lucida Console 14, на мой взгляд примерно то же самое.

Я попрошу кого-нибудь еще раз разобраться в этом

@ SteveL-MSFT Чтобы воспроизвести это, откройте командную строку, установите шрифт Consolas,
а затем запустите cmd /c chcp 65001 >NUL && powershell

Хорошо, я думаю, что определил настоящую проблему, и она не имеет ничего общего с PSReadLine. В Windows PowerShell есть проверка, поддерживается ли кодовая страница шрифтом Consolas. Список здесь . UTF-8 65001 отсутствует в этом списке, поэтому всякий раз, когда Windows PowerShell определяет кодовую страницу, которая не поддерживается Consolas, она меняет шрифт на Terminal . PowerShell Core 6.x больше не имеет этого кода, поэтому вы не видите такого поведения. Я не решаюсь менять этот код, так как он может что-то сломать. Для моих собственных заметок это находится в строке 2648 ConsoleControl.cs.

Хорошо, я думаю, что определил настоящую проблему, и она не имеет ничего общего с PSReadLine. В Windows PowerShell есть проверка, поддерживается ли кодовая страница шрифтом Consolas. Список здесь . UTF-8 65001 отсутствует в этом списке, поэтому всякий раз, когда Windows PowerShell определяет кодовую страницу, которая не поддерживается Consolas, она меняет шрифт на Terminal . PowerShell Core 6.x больше не имеет этого кода, поэтому вы не видите такого поведения. Я не решаюсь менять этот код, так как он может что-то сломать. Для моих собственных заметок это находится в строке 2648 ConsoleControl.cs.

Не уверен, как это может что-то сломать, поскольку UTF-8 не поддерживался до самых последних версий Windows 10.

@sebgod здесь что-то сломает означает неправильный рендеринг, поскольку я уверен, что у Consolas нет всех глифов, необходимых для UTF-8

@ SteveL-MSFT Lucida Console, Courier New и все другие доступные шрифты, на которые не влияет эта проблема, хотя они также не поддерживают кодовую страницу 65001. По совпадению, Consolas поддерживает больше кодовых страниц, чем Lucida Console. Так почему это происходит только с Консоласом?

Но, вообще говоря, решение о том, какой шрифт использовать для отображения, должно быть принято пользователем. Если глифов нет, они отображаются как � и пользователь может принять решение об изменении шрифта.

@Borkason Я думаю, что это очень ясная проблема с точки зрения носителей английского языка, но нет сомнений в том, что они могут вызвать проблемы для международных пользователей, которые мы не можем предвидеть.

В качестве примера, когда @bitcrazed (другой член группы Microsoft Terminal) представил PR для cURL, который будет реализовывать поддержку Windows VT https://github.com/curl/curl/pull/3011 (что включало изменение кодовой страницы на 65001), это вызвало проблему для международных пользователей: https://github.com/curl/curl/issues/3211

Это потребовало патча, который записывает UTF-8 на текущей кодовой странице, используя вместо этого широкие строковые API: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9

Меня не удивляет, что после этого команда Microsoft Terminal хочет подойти к этому очень осторожно.

@sebgod здесь что-то сломает означает неправильный рендеринг, поскольку я уверен, что у Consolas нет всех глифов, необходимых для UTF-8

Хорошо, Windows не предоставляет ни одного шрифта, который покрывает все глифы, определенные в UTF-8. Cmd.exe использует технологию, называемую связыванием шрифтов, для обеспечения рендеринга всех глифов.
До включения настройки UTF-8 в качестве системной кодовой страницы нужно было использовать chcp 65001 вручную, но это работало правильно. Бит связывания шрифтов должен быть выполнен вручную в реестре, чтобы он работал в любом случае.

@ImportTaste Я не думаю, что это имеет к этому какое-то отношение. Откат вступает в силу только при использовании Consolas. Если используется какой-либо другой шрифт, например Lucida Console или Courier New, то этого не происходит. По крайней мере, Lucida Consolas поддерживает ту же кодовую страницу, что и Consolas, поэтому трудно понять, почему это было сделано именно так. Если возникнет проблема для международных пользователей (кстати, я не являюсь носителем английского языка, как вы предполагаете), это все равно повлияет на всех пользователей, которые не используют Consolas.

На мой взгляд, запасной вариант вообще не должен быть (см. PWSH 6 + 7) или был реализован небрежно (почему только Consolas?).

@ SteveL-MSFT. И я считаю, что исправление этого вовсе не является риском, потому что ошибка появилась только в Windows версии 1809 и, очевидно, это недокументированное изменение, так как никто не знает, почему именно оно было изменено.

@Borkason Как я уже сказал, это был пример того, что что-то неожиданное пошло не так.

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

Он был обнаружен только в 1809 году, потому что шрифтом по умолчанию для консоли был Consolas. До этого, кажется, это была консоль Lucida? И для этого шрифта код работал точно так же. Насколько я понимаю, этот код (который существует с незапамятных времен и до моей команды в PowerShell Team) состоит в том, что в исходных кодах Windows у нас есть только один ярлык, используемый для PowerShell, и этот ярлык определяет шрифт по умолчанию. Поэтому, когда шрифт по умолчанию был изменен, восточноазиатские пользователи жаловались, что их глифы не отображаются, поскольку шрифт не поддерживает его. Таким образом, этот код определяет, что шрифт и языковой стандарт несовместимы, и переключает его на тот, который будет отображаться.

Я не решаюсь вносить какие-либо изменения в Windows PowerShell, поскольку даже такие, казалось бы, небольшие изменения, как это, приводят к неожиданным регрессам.

@sebgod & all: Вот несколько вещей:

Разъяснения

1. Ни на одной платформе нет единого шрифта, включающего каждый глиф для каждой кодовой точки, которая может быть представлена ​​в UTF-8.
2. Cmd.exe ничего не знает о шрифтах - Cmd.exe - это оболочка
3. Консоль (ConHost.exe) обеспечивает традиционную "терминальную" командную строку UX в Windows.
4. Текущий механизм визуализации текста в консоли не поддерживает резервный шрифт и не может отображать большинство эмодзи - попробуйте его, и вы увидите не отображаемый символ (знак вопроса в поле)

Терминал и консоль

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

Эти компоненты, в конечном итоге, будут повторно загружены в консоль, входящую в комплект поставки, но только после того, как мы выпустили Terminal v1.0, и у них будет время для тщательного тестирования в реальных условиях.

PowerShell

Как указывает @ SteveL-MSFT, в PowerShell Core (PSCore) эта проблема не возникает, и, поскольку PSCore - это будущее PowerShell, мы рекомендуем вам использовать его везде, где это возможно.

Изменить поведение PowerShell для Windows (PS) потенциально сложно, потому что, как мы знаем из попыток исправить / изменить поведение Cmd, даже небольшие, казалось бы, безобидные изменения могут привести к неожиданным сбоям в реальном мире.

При этом я буду обсуждать со Стивом и командой, и мы исследуем, можно ли изменить PS, чтобы выбрать нерастровый шрифт (например, Consolas / Lucida и т. Д.) Для кодовой страницы 65001.

@sebgod & all: Вот несколько вещей:

Разъяснения

1. Ни на одной платформе нет единого шрифта, включающего каждый глиф для каждой кодовой точки, которая может быть представлена ​​в UTF-8.

Да, именно поэтому я сказал: «Windows не предоставляет ни одного шрифта, который покрывает все глифы, определенные в UTF-8».

1. Cmd.exe ничего не знает о шрифтах - Cmd.exe - это оболочка

Да, извините за лень, я просто хотел сослаться на то, что произойдет, если вы наберете «cmd.exe» в поле поиска Windows.

1. Консоль (ConHost.exe) обеспечивает традиционную "терминальную" командную строку UX в Windows.
2. Текущий механизм визуализации текста в консоли не поддерживает резервный шрифт и не может отображать большинство эмодзи - попробуйте его, и вы увидите не отображаемый символ (знак вопроса в поле)

Как я понял, текущий движок не может отображать символы из более высоких уровней Unicode, которые включают (большинство) символов эмодзи.

Теперь я должен быть придирчивым, я говорил о Font Linking, который поддерживается или, по крайней мере, работает:

Добавив значение Lucida Console под ключ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
с типом REG_MULTI_SZ и следующими данными (или аналогичными, должны быть моноширинные шрифты):

MSGOTHIC.TTC,MS UI Gothic
MINGLIU.TTC,PMingLiU
SIMSUN.TTC,SimSun
GULIM.TTC,Gulim
YUGOTHM.TTC,Yu Gothic UI
MSJH.TTC,Microsoft JhengHei UI
MSYH.TTC,Microsoft YaHei UI
MALGUN.TTF,Malgun Gothic
SEGUISYM.TTF,Segoe UI Symbol

Можно показать большинство глифов базовой плоскости Unicode при использовании chcp 65001 или с 1803 года, установив системную кодовую страницу на UTF-8 (бета, но пока работает), что я лично предпочитаю использовать определенные кодовые страницы для каждого язык, поскольку я использую несколько языков.

Сейчас я предпочитаю использовать Consolas, который не работал с 1903 года из-за перехода на растровые шрифты.

Терминал и консоль

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

Эти компоненты, в конечном итоге, будут повторно загружены в консоль, входящую в комплект поставки, но только после того, как мы выпустили Terminal v1.0, и у них будет время для тщательного тестирования в реальных условиях.

Да, я уже использовал новый терминал UX, и, конечно, он очень приятен в использовании, но на данный момент он не позволяет вводить китайские иероглифы (надеюсь, со временем это будет исправлено)

PowerShell

Как указывает @ SteveL-MSFT, в PowerShell Core (PSCore) эта проблема не возникает, и, поскольку PSCore - это будущее PowerShell, мы рекомендуем вам использовать его везде, где это возможно.

Изменить поведение PowerShell для Windows (PS) потенциально сложно, потому что, как мы знаем из попыток исправить / изменить поведение Cmd, даже небольшие, казалось бы, безобидные изменения могут привести к неожиданным сбоям в реальном мире.

При этом я буду обсуждать со Стивом и командой, и мы исследуем, можно ли изменить PS, чтобы выбрать нерастровый шрифт (например, Consolas / Lucida и т. Д.) Для кодовой страницы 65001.

Если изменения могут что-то сломать, и мы даже не можем знать, что именно, значит, в терминале больше ничего нельзя будет изменить?

Я «исправил» проблему с помощью Powershell Core. Сначала я заметил, что ни один из параметров Powershell ничего не делает (но он изменил настройки cmd.exe). Через пару часов пробуя разные вещи, я наткнулся на Powershell Core, и как только я его загрузил, настройки, которые я сохранил, вступили в силу, как только я открыл предварительный просмотр ядра Powershell.

Возникла та же проблема при выполнении некоторых команд (включая scoop) из диспетчера FAR - этот эффект просто портит отображение FAR. Возникает только со шрифтом Consolas и включенной бета-версией для использования кодовой страницы UTF-8 (65001) в консоли. Мой язык - русский.

Как конечный пользователь - действительно раздражает, когда программа пытается быть умнее меня. Я могу жить с вопросительными знаками вместо некоторых символов UTF-8, но это изменение шрифта просто портит отображение программ, которые вообще не должны быть затронуты, например, FAR manger. Это боль.

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

У меня такая же проблема, но только если я пытаюсь использовать консоли. наверное, @ SteveL-MSFT прав.
Я попробовал Lucida Console, и все работает нормально. Полагаю, Консоласу не хватает некоторых символов для utf-8 (моя кодовая страница) ?!
Powershell Core 7 отлично работает со всеми шрифтами.

Невероятно, я купил ноутбук с Windows в 2020 году (xps15), и у меня такая же проблема. Вероятно, спустя сотни обновлений Windows, и проблема не исчезнет. Если в 2019 году будущее за PS Core, почему его не установить в 2020 году? Ядро PS может быть по умолчанию, и, возможно, старый PS может быть установлен как запасной вариант, если кому-то понадобится проблема совместимости. В любом случае, я установил Терминал Windows, и давайте попробуем.

@marcelomgarcia FWIW, причина того, что PowerShell 7 не устанавливается в Windows по умолчанию, связана с проблемами поддержки и ответственности. Windows и PowerShell 7 имеют разную поддержку, и, насколько я могу судить, юристы не придумали, как это сделать. По крайней мере, пока. Я уверен, что всем хотелось бы, чтобы PowerShell 7 входил в состав Windows 10 или Windows Server.

Помните: Windows PowerShell - это основной компонент Windows 10, и установщик по умолчанию добавляет его к вашей установленной на вашем ноутбуке. Это полностью поддерживаемый компонент FWIW. Однако, если вам нужен PowerShell 7, это отдельный и не интегрированный процесс установки.

На каком языке находится ваш компьютер?

Спасибо за объяснение @doctordns. Это просто несколько неприятная проблема, а кому-то постороннему кажется «простой». Я устанавливаю PowerShell 7.

Я использую английский (США).