Terminal: O Windows 10 1809 / 19H1 / 20H1 quebra as configurações do console do Powershell. Continua abrindo com fontes raster.

O mesmo acontece comigo apenas quando uso a fonte Consolas. Se eu usar qualquer outra coisa - Courier New, Lucida Console, etc. - as configurações serão mantidas.

@ 50Wliu posso confirmar esse comportamento. O Consolas redefine para a fonte raster. Lucida Console continua sendo Lucida Console.

Tenho quase certeza de que isso tem a ver com o fato de que a nova versão do PSReadline está usando a página de código UTF8 para exibir seu prompt e, quando faz isso, o console tenta recalcular a fonte.

Achei que tivéssemos alguns problemas para rastrear isso anteriormente, mas não consigo localizá-los. @bitcrazed você se lembra onde eles estavam? Ou era um tópico de correio interno com @lzybkr e @ SteveL-MSFT?

Alguém pode fornecer uma reprodução exata? Como qual fonte você está definindo para o atalho. Para qual fonte está sendo definido?

• Win-R e execute powershell .
• Ele começa com uma fonte raster.
• Vá em configurações e defina a fonte para Consolas. Clique OK.
• Consolas está sendo aplicado.
• Feche o Powershell.
• Reabra o PowerShell como antes.
• A fonte é uma fonte raster novamente.
• Vá para as configurações padrão e defina a fonte para Consolas. Clique OK.
• Feche o Powershell.
• Reabra o PowerShell como antes.
• A fonte é uma fonte raster novamente.

Não acho que tenha sido culpa do Powershell. Eu tenho uma nota por aqui em algum lugar que um dos mais recentes .NET Frameworks (4.7something) repentinamente decide usar 65001 como a página de código padrão para todos os aplicativos e quando isso muda para frente e para trás com outras ferramentas e páginas de código conforme eles iniciam e sair, recalculamos a fonte.

Eu tenho um bug em mim para tentar tornar isso menos doloroso, mas é realmente a mudança repentina entre as páginas de código que está tornando isso um problema.

Eu não posso reproduzir isso aqui. Tanto o Windows PowerShell quanto o Powershell são inicializados na fonte que eu defini.

@Borkason Você tentou concfg clean
https://github.com/lukesampson/concfg

@borakson - qual local o seu Windows está configurado para usar?

@bitcrazed Não sou @Borkason, mas como estou tendo esse problema, também responderei.

Meu idioma de exibição é o espanhol (Espanha), assim como meu formato regional. O idioma dos programas que não oferecem suporte a Unicode é o inglês (Estados Unidos), e marquei a caixa de seleção beta para Unicode UTF-8. (Espero que seja isso que você está procurando ... me avise se estiver pedindo outra coisa)

@bitcrazed German. E eu atualizei de 1803. Esqueci de dizer isso.

@doctordns qual fonte?

@doctordns qual fonte?

Eu uso o Lucida Console (18 pt). Mas eu testei outros e eles também funcionam após a reinicialização do Windows PowerShell.

O mesmo acontece comigo apenas quando uso a fonte Consolas. Se eu usar qualquer outra coisa - Courier New, Lucida Console, etc. - as configurações serão mantidas.

Isso provavelmente foi corrigido pelo trabalho recente de @lzybkr : https://github.com/lzybkr/PSReadLine/issues/542

@Borkason & @doctordns - você pode confirmar e fechar se corrigido?

Obrigado.

@bitcrazed , parece que o problema que você está referenciando foi corrigido em 2017 e, pelo que posso dizer, está incluído na versão do PSReadLine que acompanha o 1809. Além disso, esse problema ainda está ocorrendo para mim a partir do Windows Insiders versão 18277.

@bitcrazed É um ano mais velho que o lançamento de 1809. Eu não chamaria isso de "recente".

E para mim nada mudou. Estou no Windows 10, compilação 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

Mas como @ 50Wliu já

Aqui está um link para o feedback: https://aka.ms/AA37kk1

@bitcrazed vinculado ao problema que causou o problema.

A correção está neste PR: https://github.com/lzybkr/PSReadLine/pull/771

Justo. É conhecido com qual build a correção será enviada?

Tentarei lançar outro beta na Galeria do PowerShell antes do final do ano, mas não sei sobre o Windows (não trabalho no Windows).

@ SteveL-MSFT possui os bits que vêm no Windows, então talvez ele possa comentar.

Valor do Nome
---- -----
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

mesmo aqui ... pronto para reinstalar o windows, MUITO doloroso!

Este problema parece estar vinculado a fontes. Tive o problema no Powershell com windows (cmd e Powershell core não tem esse problema) quando defini a fonte como 'Console', mas quando alterei a fonte como 'Sarasa Mono SC', tudo funcionou perfeitamente. Eu uso 'Sarasa Mono SC' para mostrar caracteres UTF-8, o Windows 10 não tem uma fonte padrão pode mostrar caracteres UTF-8 suficientes.

O mesmo aqui. Meu Surface e PC de mesa.

Estranhamente, acho que estou enfrentando o mesmo problema, mas de uma maneira diferente. Sempre que um subprocesso é aberto para executar o powershell.exe, a fonte do console muda para raster no Consolas.

Exemplo 1: Tenho o vim em execução (WSL) e ele executa um subcomando do PowerShell para obter a área de transferência do sistema. Cada vez que executo esse comando, ele redefine a fonte do console para fontes raster.

Exemplo 2: Eu tenho um script de shell que executa o PowerShell como um subprocesso para obter os servidores de nomes do sistema. Isso faz com que a mesma coisa aconteça com o console, uma mudança para fontes raster. Nada é enviado ao console. Tudo acontece no subprocesso.

A parte realmente estranha é que se eu executar o PowerShell manualmente no console (WSL), tudo bem e a fonte não mudará.

@bitcrazed , @ SteveL-MSFT, @lzybkr : Eu tenho uma boa reprodução mínima. Isso começou a acontecer logo depois que atualizei a máquina para Windows 1809. Eu tinha a fonte e o console CP configurados antes, como abaixo, para Consolas e 65001 respectivamente, e tudo funcionou bem. Trabalho com arquivos UTF-8, então o CP 65001 tem sido essencial para mim. Minha localidade é en-US, idioma inglês, Windows 10 x64 Pro e o CP OEM é o 437 padrão.

1. Defina as seguintes chaves de registro (salve como .reg e importe). Por algum motivo, é importante alterar FontFamily, pois o padrão pode ser diferente e a fonte não será aplicada.

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. Vitória + R cmd.exe ENTER . O console começa com a fonte e a página de código corretas. Digite chcp ; ele imprime 65001 (se não, execute chcp 65001 ).
2. no console, digite powershell -noprof ('-noprof' para confirmar que o problema não está relacionado a nada que carreguei em meu perfil).

Quando o PowerShell é iniciado, a fonte do console muda imediatamente para uma fonte rasterizada e a janela é redimensionada para acomodar. A fonte raster selecionada é Terminal, e nem mesmo tem caracteres WGL4 (nem cirílico ou grego). Portanto, este é certamente um bug.

O comportamento se reproduz mesmo ao executar um comando não interativo, portanto, é bastante duvidoso que o bug esteja relacionado a PSReadLine:

powershell -noprof -nonint -command "echo foo"

Além disso, a fonte do console muda de forma semelhante (essencialmente, o console é aberto em uma fonte rasterizada) se o PowerShell for executado por meio de um atalho, da caixa de diálogo Win + R ou clicando duas vezes no Explorer.

Além disso, alguns negativos. A fonte não é alterada se:

• Eu corro chcp 437 antes de invocar powershell do cmd.
• A fonte do console é definida no registro como "Lucida Console" (todo o resto permanece igual ao anterior). Que esta fonte é de alguma forma "especial" já foi notado nos comentários deste tíquete.

O tema comum nos comentários desta edição tem sido, creio eu, uma localidade europeia não-americana (alemão e espanhol foram mencionados). Então tentei o seguinte:

1. Iniciar cmd.exe
2. Defina a página de código do console com chcp NNN (veja abaixo):
3. Execute powershell -noprof .

• Com NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - sem alteração de fonte
• Com NNN = 65001, 858 e não WGL4 hebraico 862, árabe 864 - a fonte muda.

O que diferencia o CP 858? Meu palpite é que essa pode ser a chave. O nome do CP é "OEM Multilingual Latin 1 + Euro symbol".

Também é notável que chcp 1255 e chcp 1266 (hebraico e árabe) alteram a fonte para "Courier New" mesmo em cmd.exe . Portanto, o PowerShell pode ser apenas de alguma forma mais suscetível, não o principal culpado?

Informação de versão obrigatória:

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

Além disso, devo mencionar, embora isso seja provavelmente irrelevante: eu tenho uma tela de alto DPI com a escala da tela configurada para 150%.

@ kkm000 Isso foi corrigido no PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771), mas não está na versão do Windows que você está usando, embora a correção tenha sido verificada em uma versão mais recente do Windows. Acredito que o beta público mais recente do PSReadLine tenha a correção, então você pode instalá-lo no Windows PowerShell usando:

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

Se reclamar que -AllowPrerelease não foi encontrado, você terá que atualizar o PowerShellGet:

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

embora a correção tenha sido verificada em uma versão mais recente do Windows.

Isso significa que a correção virá para um futuro lançamento (19H1) dos Insiders?

@ 50Wliu sim

@ SteveL-MSFT tenho a mesma versão que @ kkm000 , executei comandos e não funciona para mim, sinto falta de alguma coisa?

@ SteveL-MSFT Acho muito decepcionante que isso não possa ser fornecido com um Windows Update regular. Se a Microsoft interromper algo com uma atualização, é sua responsabilidade consertar com uma atualização e não adiá-la por mais de seis meses e planejar enviá-la com a próxima versão do Windows, ou fazer com que as pessoas se esforcem para obter um hotfix de um pré- repositório de

então .... eu tive que executar esse comando mais de uma vez

install-module powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber

com o Powershell rodando como admin, taskmgr para matar o Powershell e então fazer de novo, já que falhou duas ou três vezes. E… parece que está funcionando! As configurações de exibição personalizadas em meu $ PROFILE agora estão se comportando como antes da atualização.

Isso apenas começou a acontecer comigo após a atualização para a última versão 1809 17763.292 da atualização cumulativa anterior de 1809 . Segui as instruções para instalar o novo PSReadLine e parece que está lá:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
eu tenho

PSVersion 5.1.17763.134

A fonte Consolas é substituída por fontes rasterizadas.

ATUALIZAR

isso parece por correção instável. Agora, após a reinicialização, a correção está segurando / funcionando, independentemente do nível de execução.

Estou vendo um comportamento interessante. Depois de executar a 'correção' no meu laptop
Valor do Nome
---- -----
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

ao executar o PS no modo de usuário, corrigir está bem; ao executar o PS como administrador, a correção não funciona.

Não funciona para mim, mesmo no modo de usuário.

@ SteveL-MSFT, parece que a correção não funciona para mim. Além disso, não parece que o Módulo de Instalação mudou alguma coisa. Eu já tenho um PowerShellGet bem mais recente ( -AllowPrerelease certamente funciona; minhas combinações de teclas dependem de um PSReadLine recente). Instalei inicialmente o PSReadLine há alguns meses (antes de atualizar o Windows!), Então esperava obter uma atualização hoje com o seu comando sugerido, mas não tenho ideia de como confirmar se algo foi realmente alterado. Poderia ajudar por favor? Peguei a versão do PSReadLine antes de tentar a atualização:

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           : {}

Então eu atualizei, como você sugeriu:

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

O Install-Module agitou-se por um tempo, e uma barra de progresso com a picada de 'o's riscada no topo da tela. Não acredito que isso signifique nada, mas repetir o Install-Module também faz com que a barra de progresso apareça por um breve momento. Mas o novo console ainda sofre com o problema original. Além disso, não vejo nenhuma mudança aqui, talvez você possa identificar algo? Certamente posso olhar as versões de arquivo etc. que tenho, só não sei o que procurar.

Isso também não fez nada:

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

No novo console, o novo (?) PSReadLine parece o mesmo:

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           : {}

Além disso, devido aos comentários de @ mjoyce6500 e @wigster acima, verifiquei o console do usuário (não administrador) e ele também mostra o bug como antes.

Agradecemos qualquer ajuda / opinião que você possa compartilhar!

@ SteveL-MSFT, @lzybkr , não acho que haja uma atualização no PSGallery. A versão beta mais recente foi publicada um mês antes da fusão da edição 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

Infelizmente, ele não inclui mais ReleaseNotes, como o beta2 fez. Mas o tempo certamente exclui essa possibilidade.

Nota não relacionada, autor e empresa estão aparentemente trocados:

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

Author      : Microsoft Corporation
CompanyName : lzybkr

A 'correção' ainda tem resultados mistos para mim. O PowerShell no modo de usuário está funcionando bem, nenhuma alteração nas minhas cores / fontes personalizadas após executar o comando mencionado acima. Embora o Powershell no modo Admin não tenha sido corrigido, mostra o comportamento observado neste bug.

@ mjoyce6500 você pode me dar as etapas de reprodução exatas? Observe também qual versão do Windows e PSReadLine você está usando. Obrigado.

@ SteveL-MSFT, você poderia dar uma olhada no meu comentário acima ? Não consigo nem encontrar a versão atualizada do PSReadLine no PSGallery, enquanto outras pessoas relatam "resultados mistos". A partir de agora, a versão mais alta disponível ainda é PSReadLine 2.0.0-beta3 18-09-04 21:59:13 , publicada um mês antes da correção ser incorporada.

Além disso, como descubro a versão que estou usando? Em outra máquina, onde nunca tentei sua sugestão de atualização, verificando a primeira linha do arquivo Changes.txt do pacote instalado:

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

Em seguida, Install-Module realmente tenta instalar 2.0.0-beta3, confirme executando sem -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'.

É possível que eu não esteja recebendo a atualização de algum lugar que outras pessoas recebam?

Após a atualização, o Changes.txt tem o cabeçalho 2.0.0-beta3 como a primeira linha:

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

E a mesma reprodução de antes, console de administração ou não. No console cmd.exe com fonte 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>

Claro, não espero que funcione, pois não tenho a DLL atualizada. Minha pergunta é: como é possível que outras pessoas possam ter.

Tendo o mesmo problema aqui, e a correção acima não teve efeito.

Ainda é estonteante como a correção funcionou (pelo menos parcialmente) para a minoria de pessoas, uma vez que nunca foi lançada, olhando por trás deste par de olhos. Dizer que estou perplexo é não dizer nada. Meu pensamento atual é que existem DUAS galerias PS, e a correção foi publicada em uma delas que apenas algumas pessoas estão acessando.

@ kkm000 Existe um PSGallery e o beta.3 é o PSReadLine mais recente publicado. A versão do PSReadLine 2.0.0 que vem no Win10 é um fork do PSReadLine 2.0.0 com algumas correções específicas mais recentes, portanto, está à frente do publicado no PSGallery.

@ SteveL-MSFT
Instalei o beta3 e nada foi resolvido.
Ambos com Windows 1809 e 1903 (Build 18334.1)

@Borkason a correção para não alterar a fonte se não usar uma fonte raster já deve estar nessa compilação. Qual fonte você está usando?

Estou usando o Consolas. Ele volta após cada reinicialização do PowerShell.

@Borkason qual local você está usando? en-US ou algo mais?

de-DE

De repente está funcionando agora. Demorou cerca de 10 vezes para fechar e abrir o PowerShell, mas agora parece que está preso.

Quebrou novamente. Então, aparentemente, ele decide aleatoriamente quebrar novamente ou funcionar. 💢

Fiz isso acontecer com 18334 - de forma completamente aleatória. Não aconteceu de novo.

Ok, então a diferença é que, quando executo o PowerShell via ALT-R, a fonte permanece a mesma. Quando o executo a partir do menu iniciar, ele redefine a fonte para raster, mesmo quando eu a alterei para consolas na sessão anterior que executei do menu iniciar.

(E por menu iniciar, na verdade, quero dizer que pressiono a tecla Windows no teclado e, em seguida, digito 'powershell' e pressiono enter.)

@ SteveL-MSFT - Não publiquei uma versão com a correção de fonte na galeria do PowerShell. A correção está disponível no repositório PSReadLine, portanto, você pode construí-lo sozinho ou obter uma versão do AppVeyor.

@Borkason - Se você estiver usando Consolas , acho que não deveria estar vendo o bug da fonte.

Continua difícil definir os padrões do console devido à compatibilidade com versões anteriores. Os padrões podem ser definidos no registro (por aplicativo de console) ou no atalho usado para iniciar o aplicativo de console. Eu sei que a equipe do console quer resolver esse problema, mas aparentemente é um problema difícil.

Se você estiver usando Consolas então acho que você não deveria estar vendo o bug da fonte.

Então esse bug não foi resolvido, porque estou usando o Consolas e o atalho também.

Continua difícil definir os padrões do console devido à compatibilidade com versões anteriores.

Então a Microsoft deve fornecer um script / ferramenta FixIt para aqueles que querem apenas que seu console funcione novamente, independentemente da compatibilidade com versões anteriores ...

Eu sei que a equipe do console quer resolver esse problema, mas aparentemente é um problema difícil.

Pelo visto. E é obviamente também terrivelmente difícil colocar a maldita meia correção do PowerShell em 1809, para não mencionar 1903 ...

😠

Acabei de atualizar para 18342 e o problema parece ter sido corrigido (18334 ainda redefine para fontes raster todas as vezes).

Ainda concordo que a correção deve ser retroativa para 1809.

EDIT: Problema de configuração incorreta na atualização (consulte https://github.com/Microsoft/console/issues/280#issuecomment-474917761). O bug ainda não foi corrigido.

Acabei de instalar o 20H1. O problema ainda está lá. 🤣 Isso é uma piada, certo?

Isso pode ser corrigido instalando as ferramentas 1809 do Windows 10 Rsat.
Você não pode instalar o RSAT em computadores que executam as edições Home ou Standard do Windows.
Você pode instalar o RSAT apenas nas edições Windows 10 Professional ou Enterprise.

Método 1 - Usando Adicionar um Recurso Instale as ferramentas RSAT no Windows 10 versão 1809

Para instalar as ferramentas RSAT no Windows 10 versão 1809, clique em Iniciar. Clique em Configurações e, na página de configurações, clique em Aplicativos.
No painel direito, em Aplicativos e recursos, clique em Gerenciar recursos opcionais.
Agora clique em + Adicionar um recurso. Aguarde a lista de recursos a serem preenchidos.
Role para baixo até ver os recursos RSAT.
Agora selecione qualquer recurso RSAT que deseja instalar. Nesse caso, estou selecionando RSAT: recurso Ferramentas de gerenciamento de política de grupo.
Clique em Instalar.
Clique no ícone Voltar e espere até que o recurso seja instalado.
Agora você deve encontrar as Ferramentas de Gerenciamento de Política de Grupo em Iniciar> Ferramentas Administrativas do Windows.

trabalhos localizados .... Instalar ferramentas RSAT no Windows 10 versão 1809 e posterior
Por Prajwal Desai Última atualização em 31 de janeiro de 2019

Espero que isto ajude....

@RobRoberson você realmente entende o que está dizendo, certo?

Tenho o mesmo problema no Windows 1809 17763.316.
zh_Hans_CN com a opção UTF-8 habilitada.

As versões de visualização resolverão o problema?

As versões de visualização resolverão o problema?

Não.

Retiro o que disse em https://github.com/Microsoft/console/issues/280#issuecomment -465837677. O que realmente aconteceu foi que todas as minhas configurações de idioma foram redefinidas, o que desligou a página de código 65001. Acabei de perceber isso hoje, liguei-o novamente e ... olá fontes raster.

@ SteveL-MSFT, este seu

Adoraria consertar isso. Realmente gosto de Consolas para desenvolvimento em Windows.

O uso da versão interna 1903 da Microsoft pode confirmar que esse bug ainda existe para Consolas e UFT8. A fonte Lucida Console funciona e será minha solução alternativa

Estamos trabalhando em uma nova atualização para PSReadLine, então veremos como colocá-la no Windows

No pwsh 6.2.0, esse problema parecia ter sido resolvido, mas ele voltou depois que eu uso o msbuild 2017 para construir qualquer coisa (a versão de 2015 estava bem). Não tenho certeza de onde exatamente isso está acontecendo porque é de node-gyp , mas se os módulos nativos precisarem ser (re) construídos, meu console irá reverter para fontes raster.

Felizmente, não preciso mais redefinir as fontes toda vez que abro o terminal, apenas ao executar o node-gyp.

O PSReadLine 2.0.0-beta4 foi publicado e deve abordar muitos problemas (embora tenha alguns novos). https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@ SteveL-MSFT 2.0.0-beta4 não corrigiu esse bug.

Eu uso o terminal CMD normal com bash.exe + phpunit = mesmo problema do git. Ele aparece após alguns segundos do início do funcionamento do script.
Não tenho certeza do motivo no PowerShell ...

@ SteveL-MSFT 2.0.0-beta4 também não corrige o bug para mim.

@sebgod Obrigado pela dica, mudei do Consolas 16 para o Lucida Console 14, é quase a mesma coisa aos meus olhos.

Vou pedir a alguém que analise isso de novo

@ SteveL-MSFT Para replicar isso, abra um prompt de comando, defina sua fonte para Consolas,
e execute cmd /c chcp 65001 >NUL && powershell

Ok, acho que identifiquei o problema real e não tem nada a ver com PSReadLine. Há uma verificação no Windows PowerShell para ver se a página de código é compatível com a fonte Consolas. A lista está aqui . UTF-8 65001 não está nessa lista, portanto, sempre que o Windows PowerShell identifica uma página de código que não é compatível com o Consolas, ele altera a fonte para Terminal . PowerShell Core 6.x não tem mais esse código, portanto, você não vê esse comportamento. Hesito em alterar este código, pois pode interromper outra coisa. Para minhas próprias notas, isso está na linha 2648 do ConsoleControl.cs.

Ok, acho que identifiquei o problema real e não tem nada a ver com PSReadLine. Há uma verificação no Windows PowerShell para ver se a página de código é compatível com a fonte Consolas. A lista está aqui . UTF-8 65001 não está nessa lista, portanto, sempre que o Windows PowerShell identifica uma página de código que não é compatível com o Consolas, ele altera a fonte para Terminal . PowerShell Core 6.x não tem mais esse código, portanto, você não vê esse comportamento. Hesito em alterar este código, pois pode interromper outra coisa. Para minhas próprias notas, isso está na linha 2648 do ConsoleControl.cs.

Não tenho certeza de como isso pode quebrar algo, já que UTF-8 não era compatível antes das versões mais recentes do Windows 10.

@sebgod quebrar algo aqui significa renderização incorreta, pois tenho certeza de que o Consolas não tem todos os glifos necessários para UTF-8

@ SteveL-MSFT Lucida Console, Courier New e todas as outras fontes disponíveis que não são afetadas por este problema, embora também não suportem a página de códigos 65001. Coincidentemente, o Consolas ainda oferece suporte a mais páginas de código do que o Lucida Console. Então, por que isso acontece apenas com Consolas?

Mas, de modo geral, deve caber ao usuário a decisão de qual fonte será usada para exibição. Se os glifos não estiverem presentes, eles serão exibidos como � e o usuário pode tomar a decisão de alterar a fonte.

@Borkason Acho que é um problema muito claro da perspectiva de um falante nativo de inglês, mas não há dúvida de que há o medo de causar problemas para usuários internacionais que não podemos prever.

Por exemplo, quando @bitcrazed (outro membro da equipe do Microsoft Terminal) apresentou um PR ao cURL que implementaria o suporte do Windows VT https://github.com/curl/curl/pull/3011 (que envolvia alterar a página de código para 65001), acabou causando um problema para usuários internacionais: https://github.com/curl/curl/issues/3211

Isso exigiu um patch que grava UTF-8 na página de código atual usando APIs de string ampla: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9

Não me surpreende que a equipe do Terminal da Microsoft queira abordar isso com muito cuidado depois disso.

@sebgod quebrar algo aqui significa renderização incorreta, pois tenho certeza de que o Consolas não tem todos os glifos necessários para UTF-8

OK, não existe uma única fonte fornecida pelo Windows que cubra todos os glifos definidos em UTF-8. O cmd.exe depende de uma tecnologia chamada vinculação de fontes para fornecer renderização para todos os glifos.
Antes da inclusão da configuração UTF-8 como página de código do sistema, era necessário usar chcp 65001 manualmente, mas estava funcionando corretamente. O bit de link de fonte deve ser feito manualmente no registro para que funcione em qualquer caso.

@ImportTaste Não acho que isso tenha nada a ver com isso. O fallback só terá efeito se Consolas for usado. Se qualquer outra fonte for usada, como Lucida Console ou Courier New, isso não acontecerá. Pelo menos Lucida Consolas tem o mesmo suporte de página de código do Consolas, então é difícil entender por que isso foi feito dessa maneira. Se houvesse um problema para usuários internacionais (e, a propósito, não sou um falante nativo de inglês como você supõe), ainda afetaria todos os usuários que não estão usando o Consolas.

A meu ver, o fallback não deveria estar lá em primeiro lugar (veja PWSH 6 + 7) ou foi implementado mal (por que apenas Consolas?).

@ SteveL-MSFT E acredito que consertá-lo não é um risco, porque o bug foi introduzido apenas com a versão 1809 do Windows e aparentemente é uma alteração não documentada, também conhecida como ninguém sabe por que especificamente foi alterada.

@Borkason Como eu disse, foi um exemplo identificável de algo inesperado que deu errado.

Estou surpreso ao saber que é supostamente apenas uma alteração de 1809. No passado, tive problemas com a alteração da fonte do console para raster.

Só foi detectado em 1809 porque a fonte padrão do console era Consolas. Antes disso, creio que foi o Lucida Console? E o código funcionou da mesma maneira para essa fonte. Meu entendimento desse código (que está lá desde sempre e antes de minha equipe na equipe do PowerShell) é que nas fontes do Windows, temos apenas um atalho usado para o PowerShell e esse atalho define a fonte padrão. Portanto, quando a fonte padrão foi alterada, os usuários do Leste Asiático reclamaram, pois seus glifos não estavam sendo renderizados, pois a fonte não era compatível. Portanto, este código detecta que a fonte e a localidade não são compatíveis e muda para uma que será renderizada.

Hesito em fazer qualquer alteração no Windows PowerShell, pois mesmo alterações aparentemente pequenas como essa levam a regressões inesperadas.

@sebgod & all: Algumas coisas aqui:

Esclarecimentos

1. Não há uma única fonte em qualquer plataforma que inclua todos os glifos para cada ponto de código que pode ser representado em UTF-8.
2. O cmd.exe não sabe nada sobre fontes - o cmd.exe é um shell
3. Console (ConHost.exe) fornece o tradicional UX de linha de comando 'semelhante a um terminal' no Windows
4. O mecanismo de renderização de texto atual do console não suporta fallback de fonte e não pode renderizar a maioria dos emoji - experimente e você verá o caractere não exibível (ponto de interrogação em uma caixa)

Terminal e console

O Windows Terminal é nosso novo Terminal UX de última geração. Ele compartilha vários componentes comuns com o console embutido, além de adicionar vários novos recursos, incluindo um buffer de texto e um renderizador de texto que pode / irá armazenar e exibir praticamente todos os glifos Unicode.

Esses componentes serão, eventualmente, reinseridos no console embutido, mas não antes de lançarmos o Terminal v1.0 e eles terem tido tempo para serem bem testados para uso no mundo real.

PowerShell

Como @ SteveL-MSFT destaca, o PowerShell Core (PSCore) não apresenta esse problema e, como o PSCore é o futuro do PowerShell, recomendamos que você o use sempre que possível.

Alterar o comportamento do PowerShell para Windows (PS) é potencialmente difícil porque, como sabemos por tentar corrigir / alterar o comportamento do Cmd, mesmo pequenas alterações aparentemente inócuas podem resultar em uma quebra surpreendente no mundo real.

Dito isso, discutirei com Steve e a equipe e exploraremos se o PS poderia ser modificado para escolher uma fonte não raster (por exemplo, Consolas / Lucida / etc.) Para a página de código 65001.

@sebgod & all: Algumas coisas aqui:

Esclarecimentos

1. Não há uma única fonte em qualquer plataforma que inclua todos os glifos para cada ponto de código que pode ser representado em UTF-8.

Sim, é por isso que eu disse "não há uma única fonte fornecida pelo Windows que cubra todos os glifos definidos em UTF-8"

1. O cmd.exe não sabe nada sobre fontes - o cmd.exe é um shell

Sim, desculpe por ser preguiçoso, eu apenas quis dizer o que acontece se você digitar "cmd.exe" na caixa de pesquisa do Windows

1. Console (ConHost.exe) fornece o tradicional UX de linha de comando 'semelhante a um terminal' no Windows
2. O mecanismo de renderização de texto atual do console não suporta fallback de fonte e não pode renderizar a maioria dos emoji - experimente e você verá o caractere não exibível (ponto de interrogação em uma caixa)

Pelo que entendi, o motor atual não consegue processar nenhum caractere de planos Unicode superiores, o que inclui (a maioria) caracteres emoji.

Agora eu tenho que ser minucioso, eu estava falando sobre Font Linking, que é compatível ou pelo menos está funcionando:

Adicionando o valor Lucida Console na chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
com o tipo REG_MULTI_SZ e os seguintes dados (ou semelhantes, devem ser fontes monoespaçadas):

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

É possível mostrar a maioria dos glifos de plano básicos Unicode ao usar chcp 65001 ou desde 1803, definindo a página de código do sistema para UTF-8 (beta, mas funcionando até agora), que eu pessoalmente prefiro usar as páginas de código específicas para cada idioma como eu uso vários idiomas.

Agora eu prefiro usar o Consolas que não funcionava desde 1903 devido à mudança para fontes raster.

Terminal e console

O Windows Terminal é nosso novo Terminal UX de última geração. Ele compartilha vários componentes comuns com o console embutido, além de adicionar vários novos recursos, incluindo um buffer de texto e um renderizador de texto que pode / irá armazenar e exibir praticamente todos os glifos Unicode.

Esses componentes serão, eventualmente, reinseridos no console embutido, mas não antes de lançarmos o Terminal v1.0 e eles terem tido tempo para serem bem testados para uso no mundo real.

Sim, já usei o novo Terminal UX e, claro, é extremamente agradável de usar, mas não permite inserir caracteres chineses no momento (espero que isso seja corrigido eventualmente)

PowerShell

Como @ SteveL-MSFT destaca, o PowerShell Core (PSCore) não apresenta esse problema e, como o PSCore é o futuro do PowerShell, recomendamos que você o use sempre que possível.

Alterar o comportamento do PowerShell para Windows (PS) é potencialmente difícil porque, como sabemos por tentar corrigir / alterar o comportamento do Cmd, mesmo pequenas alterações aparentemente inócuas podem resultar em uma quebra surpreendente no mundo real.

Dito isso, discutirei com Steve e a equipe e exploraremos se o PS poderia ser modificado para escolher uma fonte não raster (por exemplo, Consolas / Lucida / etc.) Para a página de código 65001.

Se as mudanças podem quebrar algo e nem mesmo podemos saber o que exatamente, então nada pode ser alterado no terminal nunca mais?

Eu "consertei" o problema usando o Powershell Core. Notei pela primeira vez que nenhuma das configurações do Powershell faz nada (mas mudou as configurações em cmd.exe). Depois de algumas horas tentando coisas diferentes, deparei com o Powershell Core e assim que o baixei, as configurações que salvei antes entraram em vigor assim que abri a visualização do Powershell core.

Tenho o mesmo problema ao executar alguns dos comandos (incluindo scoop) do gerenciador FAR - esse efeito apenas estraga como FAR é mostrado. Acontece apenas com a fonte Consolas e a opção beta habilitadas para usar a página de código UTF-8 (65001) no console. Minha localidade é russa.

Como usuário final - é realmente irritante quando o programa tenta ser mais inteligente do que eu. Posso viver com pontos de interrogação em vez de alguns dos símbolos UTF-8, mas essa mudança de fonte apenas estraga a exibição de programas que não deveriam ser afetados de forma alguma, como o FAR manger. Isso é uma dor.

Por enquanto, tive que reverter para a localidade russa para o console (de volta do UTF-8), mas isso limita o trabalho com arquivos nomeados usando símbolos de outras localidades. Espero que você possa remover aquele tratamento especial de Consolas.

Tenho o mesmo problema, mas apenas se tentar usar consolas. provavelmente @ SteveL-MSFT está certo.
Eu tentei o Lucida Console e está funcionando bem. Então eu acho que Consolas está faltando alguns glifos para utf-8 (minha página de códigos) ?!
O Powershell Core 7 funciona bem com todas as fontes.

Incrível, comprei um laptop Windows em 2020 (xps15) e tenho o mesmo problema. Provavelmente centenas de atualizações do Windows depois, e o problema persiste. Se o PS Core era o futuro em 2019, por que não foi instalado em 2020? O PS Core pode ser o padrão e talvez o antigo PS possa ser instalado como substituto no caso de alguém precisar de problemas de compatibilidade. De qualquer forma, instalei o Terminal Windows e vamos experimentar.

@marcelomgarcia FWIW, o motivo pelo qual o PowerShell 7 não é instalado no Windows por padrão é devido a problemas de suporte e responsabilidade. O Windows e o PowerShell 7 têm suporte diferente e, até onde posso dizer, os advogados ainda não descobriram uma maneira de fazer isso. Por enquanto, pelo menos. Tenho certeza de que todos adorariam ver o PowerShell 7 lançado dentro do Windows 10 ou Windows Server.

Lembre-se: o Windows PowerShell é um componente principal do Windows 10 e o instalador padrão o adiciona ao instalado em seu laptop. É um componente FWIW totalmente suportado. Se você quiser o PowerShell 7, no entanto, esse é um processo de instalação separado e não integrado.

Qual idioma é o seu computador?

Obrigado pela explicação @doctordns. É um assunto um tanto frustrante e, para alguém de fora, parece um problema "simples". Estou instalando o PowerShell 7.

Eu uso o inglês dos EUA.