Terminal: Windows 10 1809 / 19H1 / 20H1 rompe la configuración de la consola de Powershell. Sigue abriéndose con fuentes rasterizadas.

A mí me pasa lo mismo solo cuando utilizo la fuente Consolas. Si utilizo cualquier otra cosa (Courier New, Lucida Console, etc.), la configuración se conserva.

@ 50Wliu Puedo confirmar ese comportamiento. Consolas se restablece a la fuente de trama. Lucida Console permanece Lucida Console.

Estoy casi seguro de que esto tiene que ver con el hecho de que la nueva versión de PSReadline está usando la página de códigos UTF8 para mostrar su mensaje, y cuando lo hace, la consola intenta recalcular la fuente.

Pensé que teníamos algunos problemas para rastrear esto anteriormente, pero parece que no puedo encontrarlos. @bitcrazed ¿recuerdas dónde estaban? ¿O fue un hilo de correo interno con @lzybkr y @ SteveL-MSFT?

¿Alguien puede proporcionar una reproducción exacta? Como qué fuente estás configurando para el acceso directo. ¿En qué fuente se está configurando?

• Win-R y ejecute powershell .
• Comienza con una fuente rasterizada.
• Vaya a la configuración y establezca la fuente en Consolas. Haga clic en Aceptar.
• Se está aplicando Consolas.
• Cierre Powershell.
• Vuelve a abrir powershell como antes.
• La fuente es fuente de trama nuevamente.
• Vaya a la configuración predeterminada y establezca la fuente en Consolas. Haga clic en Aceptar.
• Cierre Powershell.
• Vuelve a abrir powershell como antes.
• La fuente es fuente de trama nuevamente.

No creo que esto haya sido culpa de Powershell. Tengo una nota por aquí en algún lugar de que uno de los Frameworks .NET más recientes (4.7something) repentinamente decide usar 65001 como la página de códigos predeterminada para todas las aplicaciones y cuando eso cambia de un lado a otro con otras herramientas y páginas de códigos a medida que comienzan y salir, recalculamos la fuente.

Tengo un error para intentar que eso sea menos doloroso, pero en realidad es el cambio repentino entre páginas de códigos lo que hace que esto sea un problema.

No puedo reproducir esto aquí. Tanto Windows PowerShell como Powershell se inician con la fuente que configuré.

@Borkason ¿Has probado concfg clean
https://github.com/lukesampson/concfg

@borakson : ¿qué configuración regional está configurada para usar su Windows?

@bitcrazed No soy @Borkason, pero como estoy experimentando este problema, también responderé.

Mi idioma de visualización es el español (España), al igual que mi formato regional. El idioma de los programas que no son compatibles con Unicode es el inglés (Estados Unidos) y tengo la casilla de verificación beta seleccionada para UTF-8 Unicode. (Espero que eso sea lo que estás buscando ... avísame si estabas pidiendo algo más)

@bitcrazed alemán. Y me actualicé desde 1803. Se me olvidó decir eso.

@doctordns ¿ qué fuente?

@doctordns ¿ qué fuente?

Yo uso Lucida Console (18 pt). Pero he probado otros y también funcionan después de reiniciar Windows PowerShell.

A mí me pasa lo mismo solo cuando utilizo la fuente Consolas. Si utilizo cualquier otra cosa (Courier New, Lucida Console, etc.), la configuración se conserva.

Esto probablemente fue solucionado por el trabajo reciente de @lzybkr : https://github.com/lzybkr/PSReadLine/issues/542

@Borkason & @doctordns : ¿puede confirmar y cerrar si se solucionó?

Gracias.

@bitcrazed , parece que el problema al que hace referencia se solucionó en 2017 y, por lo que puedo decir, está incluido en la versión de PSReadLine con la que se envía 1809. Además, este problema me sigue ocurriendo a partir de la compilación 18277 de Windows Insiders.

@bitcrazed Eso es un año más antiguo que el lanzamiento de 1809. Yo no llamaría a eso "reciente".

Y para mí nada cambió. Estoy en Windows 10 compilación 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

Pero como @ 50Wliu ya dijo, ni siquiera está arreglado en la vista previa actual.

Aquí hay un enlace a los comentarios: https://aka.ms/AA37kk1

@bitcrazed vinculado al problema que causó el problema.

La solución está en este PR: https://github.com/lzybkr/PSReadLine/pull/771

Lo suficientemente justo. ¿Se sabe con qué compilación se enviará la solución?

Intentaré lanzar otra versión beta de la Galería de PowerShell antes de fin de año, pero no sé nada de Windows (no trabajo en Windows).

@ SteveL-MSFT posee los bits que se envían en Windows, así que tal vez él pueda comentar.

Valor de nombre
---- -----
PSVersion 5.1.17763.134
Escritorio PSEdition
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0 ...}
BuildVersion 10.0.17763.134
CLR Versión 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Lo mismo aquí ... listo para reinstalar Windows, ¡REALMENTE doloroso!

Este problema parece enlaces a fuentes. Tuve el problema en Powershell con Windows (cmd y Powershell core no tienen este problema) cuando configuro la fuente como 'Consola', pero cuando cambio la fuente como 'Sarasa Mono SC', todo funciona perfectamente. Utilizo 'Sarasa Mono SC' para mostrar caracteres UTF-8, Windows 10 no tiene una fuente predeterminada que pueda mostrar suficientes caracteres UTF-8.

Igual que aquí. Tanto mi Surface como mi PC de escritorio.

Curiosamente, creo que estoy experimentando este mismo problema pero de una manera diferente. Siempre que se abre un subproceso para ejecutar powershell.exe, la fuente de la consola cambia a ráster desde Consolas.

Ejemplo 1: tengo vim en ejecución (WSL) y ejecuta un subcomando de powershell para obtener el portapapeles del sistema. Cada vez que ejecuto ese comando, restablece la fuente de la consola a fuentes rasterizadas.

Ejemplo 2: Tengo un script de shell que ejecuta powershell como un subproceso para obtener los servidores de nombres del sistema. Hace que suceda lo mismo con la consola, un cambio a fuentes rasterizadas. No se envía nada a la consola. Todo sucede en el subproceso.

La parte realmente extraña es que si ejecuto powershell manualmente desde la consola (WSL), está bien y la fuente no cambia.

@bitcrazed , @ SteveL-MSFT, @lzybkr : Tengo una buena reproducción mínima. Esto comenzó a suceder justo después de que actualicé la máquina a Windows 1809. Tenía la fuente y la consola CP configuradas antes, como se muestra a continuación, en Consolas y 65001 respectivamente, y todo funcionó bien. Trabajo con archivos UTF-8, por eso el CP 65001 ha sido fundamental para mí. Mi configuración regional es en-US, en inglés, Windows 10 x64 Pro, y el OEM CP es el 437 predeterminado.

1. Configure las siguientes claves de registro (guardar como .reg e importar). Por alguna razón, es importante cambiar FontFamily, ya que el valor predeterminado puede ser diferente y la fuente no se aplicará.

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. Gana + R cmd.exe ENTER . La consola comienza con la fuente y la página de códigos correctas. Escriba chcp ; imprime 65001 (si no lo hace, ejecute chcp 65001 ).
2. en la consola, escriba powershell -noprof ('-noprof' para confirmar que el problema no está relacionado con nada de lo que cargo en mi perfil).

Cuando se inicia PowerShell, la fuente de la consola cambia inmediatamente a una fuente ráster y la ventana cambia de tamaño para adaptarse. La fuente de trama seleccionada es Terminal, y ni siquiera tiene caracteres WGL4 (ni cirílico ni griego). Entonces esto es ciertamente un error.

El comportamiento se reproduce incluso si se ejecuta un comando no interactivo, por lo que es bastante dudoso que el error esté relacionado con PSReadLine:

powershell -noprof -nonint -command "echo foo"

Además, la fuente de la consola cambia de manera similar (esencialmente, la consola se abre en una fuente ráster) si PowerShell se ejecuta a través de un acceso directo, o desde el cuadro de diálogo Win + R, o haciendo doble clic en el Explorador.

Además, algunos aspectos negativos. La fuente no se cambia si:

• Ejecuto chcp 437 antes de invocar powershell desde cmd.
• La fuente de la consola está configurada en el registro como "Lucida Console" (todo lo demás permanece igual que el anterior). Que esta fuente es de alguna manera "especial" ya se ha señalado en los comentarios de este ticket.

El tema común en los comentarios de este número ha sido, creo, un lugar europeo no estadounidense (se mencionaron alemán y español). Entonces probé lo siguiente:

1. Inicie cmd.exe
2. Configure la página de códigos de la consola con chcp NNN (ver más abajo):
3. Ejecute powershell -noprof .

• Con NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - sin cambio de fuente
• Con NNN = 65001, 858 y no WGL4 Hebrew 862, Arabic 864 - la fuente cambia.

¿Qué distingue al CP 858? Supongo que esta puede ser la clave. El nombre del CP es "OEM multilingüe latino 1 + símbolo del euro".

También es notable que chcp 1255 y chcp 1266 (hebreo y árabe) cambian la fuente a "Courier New" incluso en cmd.exe . Entonces, ¿PowerShell puede ser solo de alguna manera más susceptible, no el principal culpable?

Información de la versión obligatoria:

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

Además, debo mencionar, aunque esto probablemente sea irrelevante: tengo una pantalla de alto DPI con la escala de pantalla establecida en 150%.

@ kkm000 Esto se corrigió en PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771), pero no está en la compilación de Windows que está utilizando, aunque la corrección se registró en una compilación más nueva de Windows. Creo que la versión Beta pública más reciente de PSReadLine tiene la solución, por lo que puede instalarla en Windows PowerShell usando:

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

Si se queja de que no se encuentra -AllowPrerelease , tendrá que actualizar PowerShellGet:

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

aunque la solución se registró en una versión más reciente de Windows.

¿Significa esto que la solución llegará en un futuro lanzamiento de Insiders (19H1)?

@ 50Wliu sí

@ SteveL-MSFT tengo la misma versión que @ kkm000 , ejecuté sus comandos y no me funcionan, ¿me pierdo algo?

@ SteveL-MSFT Me resulta muy decepcionante que esto no se pueda enviar con una actualización de Windows normal. Si Microsoft rompe algo con una actualización, es su responsabilidad de fijarlo con una actualización y no posponer por más de seis meses y un plan para enviar con la próxima versión de Windows, o que la gente pasar por el aro para obtener una revisión de un pre- lanzamiento del repositorio (que ni siquiera funciona para todos).

así que ... tuve que ejecutar ese comando más de una vez

instalar-módulo powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber

con powershell ejecutándose como administrador, taskmgr para matar a powershell y luego hacerlo de nuevo ya que falló dos o tres veces. Y ... ¡parece que está funcionando! La configuración de pantalla personalizada en mi $ PROFILE ahora se comporta como estaba antes de la actualización.

Esto acaba de comenzar a sucederme después de la actualización a la última compilación 1809 17763.292 de la actualización acumulativa 1809 anterior. Seguí las instrucciones para instalar el nuevo PSReadLine y parece estar ahí:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
yo tengo

PSVersion 5.1.17763.134

La fuente Consolas se reemplaza con fuentes rasterizadas.

ACTUALIZAR

esto parece ser una solución inestable. Ahora, después de reiniciar, la solución se mantiene / funciona, independientemente del nivel de ejecución.

Comportamiento interesante que estoy viendo ahora. Después de ejecutar el 'arreglo' en mi computadora portátil
Valor de nombre
---- -----
PSVersion 5.1.17763.134
Escritorio PSEdition
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0 ...}
BuildVersion 10.0.17763.134
CLR Versión 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

cuando se ejecuta PS en modo de usuario, la corrección está bien; cuando se ejecuta PS como administrador, la corrección no funciona.

No me funciona incluso en modo de usuario.

@ SteveL-MSFT, parece que la solución no me funciona. Además, no parece que el módulo de instalación haya cambiado nada. Ya tengo un PowerShellGet bastante más reciente ( -AllowPrerelease ciertamente funciona; mis combinaciones de teclas dependen de una PSReadLine reciente). Inicialmente instalé PSReadLine hace unos meses (¡antes de actualizar Windows!), Por lo que esperaba obtener una actualización hoy con el comando sugerido, pero no tengo idea de cómo confirmar si de hecho se ha cambiado algo. ¿Podrias ayudarme por favor? Tomé la versión de PSReadLine antes de intentar la actualización:

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

Luego actualicé, como sugirió:

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

El Install-Module agitó por un tiempo, y una barra de progreso con la picadura de 'o's rayada en la parte superior de la pantalla. No creo que esto signifique nada, pero repetir el módulo de instalación también hace que la barra de progreso aparezca por un breve momento. Pero la nueva consola aún sufre el problema original. Además, no veo ningún cambio aquí, ¿tal vez podrías detectar algo? Ciertamente puedo ver las versiones de archivo, etc. que tengo, solo que no sé qué buscar.

Esto tampoco hizo nada:

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

En la nueva consola, la nueva (?) PSReadLine parece la misma:

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

Además, debido a los comentarios de @ mjoyce6500 y @wigster anteriores, verifiqué la consola del usuario (no administrador), y también muestra el error como lo hacía antes.

Por favor, agradeceré cualquier ayuda / pensamiento que pueda compartir.

@ SteveL-MSFT, @lzybkr , no creo que haya una actualización en PSGallery. La última versión beta se publicó un mes antes de que se fusionara el problema 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

Desafortunadamente, ya no incluye ReleaseNotes, como lo hizo beta2. Pero el tiempo ciertamente excluye esta posibilidad.

Nota no relacionada, autor y empresa aparentemente se intercambian:

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

Author      : Microsoft Corporation
CompanyName : lzybkr

La 'solución' todavía tiene resultados mixtos para mí. Powershell en modo de usuario funciona bien, no hay cambios en mis colores / fuentes personalizados después de ejecutar el comando mencionado anteriormente. Aunque Powershell en modo Administrador no se corrigió, muestra el comportamiento observado en este error.

@ mjoyce6500 ¿puedes darme los pasos exactos de reproducción? También tenga en cuenta qué compilación de Windows y PSReadLine está utilizando. Gracias.

@ SteveL-MSFT, ¿podría echar un vistazo a mi comentario anterior ? Ni siquiera puedo encontrar la versión actualizada de PSReadLine en PSGallery, mientras que otras personas informan "resultados mixtos". En este momento, la versión más alta disponible sigue siendo PSReadLine 2.0.0-beta3 18-09-04 21:59:13 , publicada un mes antes de que se fusionara la corrección.

Además, ¿cómo averiguo la versión que estoy usando? En otra máquina, donde nunca intenté su sugerencia de actualización, verificando la primera línea del archivo Changes.txt del paquete 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

Luego, Install-Module intenta instalar 2.0.0-beta3, confirme ejecutando sin -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'.

¿Es posible que no reciba la actualización de algún otro lugar?

Después de la actualización, Changes.txt tiene el encabezado 2.0.0-beta3 como primera línea:

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

Y la misma reproducción que antes, consola de administración o no. Desde la consola cmd.exe con fuente 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>

Por supuesto, no espero que funcione, ya que no tengo la DLL actualizada. Mi pregunta es, ¿cómo es posible que otras personas puedan tenerlo?

Tener el mismo problema aquí, y la solución anterior no ha tenido ningún efecto.

Todavía es asombroso cómo funcionó la solución (al menos parcialmente) para la minoría de personas, dado que nunca se lanzó, mirando desde detrás de este par de ojos. Decir que estoy desconcertado es no decir nada. Mi opinión actual es que hay DOS galerías de PS, y la solución se ha publicado en una de ellas a la que solo acceden unas pocas personas.

@ kkm000 Hay una PSGallery y beta.3 es la última PSReadLine publicada. La versión de PSReadLine 2.0.0 que se incluye en Win10 es una bifurcación de PSReadLine 2.0.0 con algunas correcciones específicas más nuevas, por lo que en ese sentido está por delante de la publicada en PSGallery.

@ SteveL-MSFT
Instalé beta3 y no se resuelve
Ambos con Windows 1809 y 1903 (compilación 18334.1)

@Borkason, la solución para no cambiar la fuente si no se usa una fuente rasterizada ya debería estar en esa compilación. ¿Qué fuente está usando?

Estoy usando Consolas. Vuelve a cambiar después de cada reinicio de PowerShell.

@Borkason ¿qué configuración regional estás usando? en-US o algo más?

de-DE

De repente está funcionando ahora. Me tomó como 10 veces cerrar y abrir el PowerShell, pero ahora parece que se pega.

Se rompió de nuevo. Entonces, aparentemente, decide al azar volver a romperse o funcionar. 💢

Tuve que pasar con 18334, completamente al azar. No volvió a pasar.

Bien, entonces la diferencia es que cuando ejecuto powershell a través de ALT-R, la fuente permanece igual. Cuando lo ejecuto desde el menú de inicio, restablece la fuente a ráster, incluso cuando la cambié a consolas en la sesión anterior que ejecuté desde el menú de inicio.

(Y por menú de inicio me refiero a que presiono la tecla de Windows en el teclado y luego escribo 'powershell' y presiono enter).

@ SteveL-MSFT: no he publicado una versión con la corrección de fuentes en la galería de PowerShell. Sin embargo, la solución está disponible en el repositorio de PSReadLine, por lo que puede compilarlo usted mismo o tomar una compilación de AppVeyor.

@Borkason : si estás usando Consolas , creo que no deberías estar viendo el error de fuente.

Sigue siendo difícil establecer los valores predeterminados de la consola debido a la compatibilidad con versiones anteriores. Los valores predeterminados se pueden establecer en el registro (por aplicación de consola) o en el acceso directo utilizado para iniciar la aplicación de consola. Sé que el equipo de la consola quiere resolver ese problema, pero aparentemente es un problema difícil.

Si está usando Consolas , creo que no debería ver el error de fuente.

Entonces este error no se resuelve, porque estoy usando Consolas y el atajo también.

Sigue siendo difícil establecer los valores predeterminados de la consola debido a la compatibilidad con versiones anteriores.

Entonces, Microsoft debería proporcionar un script / herramienta FixIt para aquellos que solo quieren que su consola vuelva a funcionar, independientemente de la compatibilidad con versiones anteriores ...

Sé que el equipo de la consola quiere resolver ese problema, pero aparentemente es un problema difícil.

Aparentemente. Y, obviamente, también es terriblemente difícil poner la maldita media corrección de PowerShell en 1809, sin mencionar 1903 ...

😠

Acabo de actualizar a 18342 y el problema parece estar solucionado (18334 todavía se restablece a las fuentes de trama cada vez).

Aún estoy de acuerdo en que la corrección debería ser retroportada a 1809.

EDITAR: Problema de configuración incorrecta en la actualización (consulte https://github.com/Microsoft/console/issues/280#issuecomment-474917761). El error aún no se ha solucionado.

Acabo de hacer una nueva instalación de 20H1. El problema sigue ahí. 🤣 Esto es una broma, ¿verdad?

Esto se puede solucionar instalando las herramientas 1809 Windows 10 Rsat.
No puede instalar RSAT en equipos que ejecutan las ediciones Home o Standard de Windows.
Puede instalar RSAT solo en las ediciones Windows 10 Professional o Enterprise.

Método 1: usar Agregar una función Instalar herramientas RSAT en Windows 10 versión 1809

Para instalar RSAT Tools en Windows 10 versión 1809, haga clic en Inicio. Haga clic en Configuración y desde la página de configuración, haga clic en Aplicaciones.
En el panel derecho, en Aplicaciones y funciones, haga clic en Administrar funciones opcionales.
Ahora haga clic en + Agregar una función. Espere a que se complete la lista de funciones.
Desplácese hacia abajo hasta que vea las funciones de RSAT.
Ahora seleccione cualquiera de las funciones RSAT que desee instalar. En este caso, estoy seleccionando RSAT: función de herramientas de administración de políticas de grupo.
Haga clic en Instalar.
Haga clic en el icono de retroceso y espere hasta que se instale la función.
Ahora debería encontrar las Herramientas de administración de políticas de grupo en Inicio> Herramientas administrativas de Windows.

funciona ubicado ... Instale RSAT Tools en Windows 10 versión 1809 y posterior
Por Prajwal Desai Última actualización 31 de enero de 2019

Espero que esto ayude....

@RobRoberson , realmente entiendes lo que estás diciendo, ¿verdad?

Tengo el mismo problema en Windows 1809 17763.316.
zh_Hans_CN con la opción UTF-8 habilitada.

¿Resolverán el problema las versiones de vista previa?

¿Resolverán el problema las versiones de vista previa?

No.

Retiro lo que dije en https://github.com/Microsoft/console/issues/280#issuecomment -465837677. Lo que realmente sucedió fue que se restablecieron todas mis configuraciones de idioma, lo que desactivó la página de códigos 65001. Me acabo de dar cuenta de eso hoy, lo volví a encender y ... hola, fuentes ráster.

@ SteveL-MSFT, este comentario suyo parece incorrecto por la cantidad de personas que siguen diciendo que este problema no está resuelto, incluso en las últimas versiones de Insider (estoy en 18361 en este momento, por ejemplo).

Me encantaría arreglar esto. Realmente me gusta Consolas para el desarrollo bajo Windows.

El uso de la versión interna de Microsoft 1903 puede confirmar que este error aún existe para Consolas y UFT8. Sin embargo, la fuente Lucida Console funciona y será mi solución

Estamos trabajando en una nueva actualización de PSReadLine, luego veremos cómo instalarla en Windows.

En pwsh 6.2.0, este problema parecía haberse resuelto, pero volvió después de usar msbuild 2017 para compilar cualquier cosa (la versión 2015 estaba bien). No estoy seguro de dónde está sucediendo exactamente esto porque es de node-gyp , pero si los módulos nativos necesitan ser (re) construidos, mi consola volverá a las fuentes ráster.

Afortunadamente, ya no tengo que restablecer las fuentes cada vez que abro la terminal, solo cuando ejecuto node-gyp.

Se publicó PSReadLine 2.0.0-beta4 que debería abordar muchos problemas (aunque tiene algunos nuevos). https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@ SteveL-MSFT 2.0.0-beta4 no solucionó este error.

Utilizo una terminal CMD normal con bash.exe + phpunit = mismo problema de git. Aparece después de unos segundos de que el script comience a funcionar.
No estoy seguro de la razón en PowerShell ...

@ SteveL-MSFT 2.0.0-beta4 tampoco me corrige el error.

@sebgod Gracias por el consejo,

Haré que alguien mire esto de nuevo

@ SteveL-MSFT Para replicar esto, abra un símbolo del sistema, configure su fuente en Consolas,
y luego ejecute cmd /c chcp 65001 >NUL && powershell

Ok, creo que identifiqué el problema real y no tiene nada que ver con PSReadLine. Hay una comprobación en Windows PowerShell para ver si la página de códigos es compatible con la fuente Consolas. La lista está aquí . UTF-8 65001 no está en esa lista, por lo que siempre que Windows PowerShell identifica una página de códigos que no es compatible con Consolas, cambiará la fuente a Terminal . PowerShell Core 6.x ya no tiene este código, por lo que no ve este comportamiento. Dudo en cambiar este código, ya que puede romper algo más. Para mis propias notas, esto está en ConsoleControl.cs línea 2648.

Ok, creo que identifiqué el problema real y no tiene nada que ver con PSReadLine. Hay una comprobación en Windows PowerShell para ver si la página de códigos es compatible con la fuente Consolas. La lista está aquí . UTF-8 65001 no está en esa lista, por lo que siempre que Windows PowerShell identifica una página de códigos que no es compatible con Consolas, cambiará la fuente a Terminal . PowerShell Core 6.x ya no tiene este código, por lo que no ve este comportamiento. Dudo en cambiar este código, ya que puede romper algo más. Para mis propias notas, esto está en ConsoleControl.cs línea 2648.

No estoy seguro de cómo esto puede romper algo, ya que UTF-8 no era compatible antes de las versiones más recientes de Windows 10.

@sebgod romper algo aquí significa una representación incorrecta, ya que estoy seguro de que Consolas no tiene todos los glifos necesarios para UTF-8

@ SteveL-MSFT Lucida Console, Courier New y todas las demás fuentes disponibles que no se ven afectadas por este problema, aunque tampoco son compatibles con la página de códigos 65001. Casualmente, Consolas incluso admite más páginas de códigos que Lucida Console. Entonces, ¿por qué sucede esto solo con Consolas?

Pero en términos generales, debería ser la decisión de los usuarios la fuente que se utilice para mostrar. Si los glifos no están presentes, se muestran como � y el usuario puede tomar la decisión de cambiar la fuente.

@Borkason Creo que es un tema muy claro desde la perspectiva de un angloparlante nativo, pero no hay duda de que existe el temor de causar problemas a los usuarios internacionales que no somos capaces de prever.

Como ejemplo, cuando @bitcrazed (otro miembro del equipo de Microsoft Terminal) introdujo un PR para cURL que implementaría el soporte de Windows VT https://github.com/curl/curl/pull/3011 (que implicaba cambiar la página de códigos a 65001), terminó causando un problema para los usuarios internacionales: https://github.com/curl/curl/issues/3211

Esto requirió un parche que escribe UTF-8 en la página de códigos actual utilizando API de cadena ancha en su lugar: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9

No me sorprende que el equipo de Microsoft Terminal quiera abordar esto con mucho cuidado después de eso.

@sebgod romper algo aquí significa una representación incorrecta, ya que estoy seguro de que Consolas no tiene todos los glifos necesarios para UTF-8

De acuerdo, Windows no proporciona una sola fuente que cubra todos los glifos definidos en UTF-8. Cmd.exe se basa en una tecnología llamada enlace de fuentes para proporcionar renderizado para todos los glifos.
Antes de la inclusión de configurar UTF-8 como la página de códigos del sistema, se tenía que usar chcp 65001 manualmente, pero estaba funcionando correctamente. El bit de enlace de fuentes debe realizarse manualmente en el registro para que funcione en cualquier caso.

@ImportTaste No creo que eso tenga nada que ver con eso. La alternativa solo entra en vigor si se utiliza Consolas. Si se utiliza cualquier otra fuente como Lucida Console o Courier New, esto no sucede. Al menos Lucida Consolas tiene el mismo soporte de página de códigos que Consolas, por lo que es difícil entender por qué se hizo de esta manera. Si hubiera un problema para los usuarios internacionales (y por cierto, no soy un hablante nativo de inglés como usted asume), aún afectaría a todos los usuarios que no están usando Consolas.

A mi modo de ver, el respaldo no debería estar allí en primer lugar (ver PWSH 6 + 7) o se implementó de manera descuidada (¿por qué solo Consolas?).

@ SteveL-MSFT Y creo que arreglarlo no es un riesgo en absoluto, porque el error se introdujo solo con la versión 1809 de Windows y aparentemente es un cambio indocumentado, es decir, nadie sabe por qué se cambió específicamente.

@Borkason Como dije, fue un ejemplo identificable de algo inesperado que salió mal.

Me sorprende escuchar que supuestamente es solo un cambio de 1809, he tenido problemas con la fuente de la consola cambiando a raster en el pasado.

Solo se detectó en 1809 porque la fuente predeterminada para la consola era Consolas. Antes de eso, creo que fue Lucida Console. Y el código funcionó de la misma manera para esa fuente. Mi comprensión de ese código (que ha estado allí desde siempre y antes de mi equipo en el equipo de PowerShell) es que en las fuentes de Windows, solo tenemos un atajo usado para PowerShell y ese atajo define la fuente predeterminada. Entonces, cuando se cambió la fuente predeterminada, los usuarios de Asia oriental se quejaron porque sus glifos no se estaban renderizando porque la fuente no la admite. Entonces, este código detecta que la fuente y la configuración regional no son compatibles y lo cambia a uno que se procese.

Dudo en realizar cambios en Windows PowerShell, ya que incluso cambios aparentemente pequeños como este conducen a regresiones inesperadas.

@sebgod & all: Algunas cosas aquí:

Aclaraciones

1. No existe una fuente única en ninguna plataforma que incluya todos los glifos para cada punto de código que se puede representar en UTF-8.
2. Cmd.exe no sabe nada sobre fuentes: Cmd.exe es un shell
3. Console (ConHost.exe) proporciona la experiencia de usuario de línea de comandos tradicional 'similar a un terminal' en Windows
4. El motor de procesamiento de texto actual de la consola no admite el respaldo de fuentes y no puede procesar la mayoría de los emoji; pruébelo y verá el carácter no visualizable (signo de interrogación en un cuadro)

Terminal y consola

Windows Terminal es nuestro nuevo Terminal UX de próxima generación. Comparte varios componentes comunes con la consola en caja, además de que agrega varias características nuevas que incluyen un búfer de texto y un renderizador de texto que puede almacenar y mostrar prácticamente todos los glifos Unicode.

Estos componentes, eventualmente, se volverán a ingerir en la Consola incluida, pero no hasta que hayamos lanzado Terminal v1.0 y hayan tenido tiempo de probarse bien en el mundo real.

Potencia Shell

Como señala @ SteveL-MSFT, PowerShell Core (PSCore) no presenta este problema y, dado que PSCore es el futuro de PowerShell, lo alentamos a que lo use siempre que sea posible.

Cambiar el comportamiento de PowerShell para Windows (PS) es potencialmente difícil porque, como sabemos por intentar arreglar / cambiar el comportamiento de Cmd, incluso pequeños cambios aparentemente inocuos pueden resultar en una rotura sorprendente en el mundo real.

Dicho esto, lo discutiré con Steve & Team y exploraremos si PS podría modificarse para elegir una fuente no rasterizada (por ejemplo, Consolas / Lucida / etc.) para la página de códigos 65001.

@sebgod & all: Algunas cosas aquí:

Aclaraciones

1. No existe una fuente única en ninguna plataforma que incluya todos los glifos para cada punto de código que se puede representar en UTF-8.

Sí, por eso dije "no hay una sola fuente proporcionada por Windows que cubra todos los glifos definidos en UTF-8".

1. Cmd.exe no sabe nada sobre fuentes: Cmd.exe es un shell

Sí, lo siento por ser perezoso, solo quería referirme a lo que sucede si escribe "cmd.exe" en el cuadro de búsqueda de Windows

1. Console (ConHost.exe) proporciona la experiencia de usuario de línea de comandos tradicional 'similar a un terminal' en Windows
2. El motor de procesamiento de texto actual de la consola no admite el respaldo de fuentes y no puede procesar la mayoría de los emoji; pruébelo y verá el carácter no visualizable (signo de interrogación en un cuadro)

Según entendí, el motor actual no puede representar ningún carácter de planos Unicode superiores, que incluyen (la mayoría) de los caracteres emoji.

Ahora tengo que ser quisquilloso, estaba hablando de Font Linking, que es compatible o al menos funciona:

Añadiendo el valor Lucida Console debajo de la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
con el tipo REG_MULTI_SZ y los siguientes datos (o similares, deben ser fuentes monoespaciadas):

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

Es posible mostrar la mayoría de los glifos de plano básico Unicode cuando se usa chcp 65001 o desde 1803 configurando la página de códigos del sistema en UTF-8 (beta pero funcionando hasta ahora), que personalmente prefiero usar las páginas de códigos específicas para cada uno. idioma ya que utilizo varios idiomas.

Ahora prefiero usar Consolas que no funcionaba desde 1903 debido a que cambió a fuentes rasterizadas.

Terminal y consola

Windows Terminal es nuestro nuevo Terminal UX de próxima generación. Comparte varios componentes comunes con la consola en caja, además de que agrega varias características nuevas que incluyen un búfer de texto y un renderizador de texto que puede almacenar y mostrar prácticamente todos los glifos Unicode.

Estos componentes, eventualmente, se volverán a ingerir en la Consola incluida, pero no hasta que hayamos lanzado Terminal v1.0 y hayan tenido tiempo de probarse bien en el mundo real.

Sí, ya he usado el nuevo Terminal UX y, por supuesto, es extremadamente agradable de usar, pero no permite ingresar caracteres chinos en este momento (espero que esto se solucione eventualmente)

Potencia Shell

Como señala @ SteveL-MSFT, PowerShell Core (PSCore) no presenta este problema y, dado que PSCore es el futuro de PowerShell, lo alentamos a que lo use siempre que sea posible.

Cambiar el comportamiento de PowerShell para Windows (PS) es potencialmente difícil porque, como sabemos por intentar arreglar / cambiar el comportamiento de Cmd, incluso pequeños cambios aparentemente inocuos pueden resultar en una rotura sorprendente en el mundo real.

Dicho esto, lo discutiré con Steve & Team y exploraremos si PS podría modificarse para elegir una fuente no rasterizada (por ejemplo, Consolas / Lucida / etc.) para la página de códigos 65001.

¿Si los cambios pueden romper algo e incluso no podemos saber qué exactamente, entonces nada se puede cambiar en el terminal nunca más?

"Solucioné" el problema usando Powershell Core. Primero noté que ninguna de las configuraciones de Powershell hace nada (pero sí cambió la configuración en cmd.exe). Después de un par de horas de probar cosas diferentes, me topé con Powershell Core y, tan pronto como lo descargué, la configuración que guardé antes surtió efecto tan pronto como abrí la vista previa del núcleo de Powershell.

Tuve el mismo problema al ejecutar algunos de los comandos (incluida la primicia) del administrador FAR: este efecto simplemente arruina cómo se muestra FAR. Ocurre solo con la fuente Consolas y la opción beta habilitada para usar la página de códigos UTF-8 (65001) en la consola. Mi localidad es rusa.

Como usuario final, es realmente molesto cuando el programa intenta ser más inteligente que yo. Puedo vivir con signos de interrogación en lugar de algunos símbolos UTF-8, pero este cambio de fuente solo arruina la visualización de programas que no deberían verse afectados en absoluto, como FAR manger. Esto es un dolor.

Por ahora, tuve que volver a la configuración regional rusa para la consola (desde UTF-8), pero esto limita el trabajo con archivos nombrados con símbolos de otras configuraciones regionales. Espero que puedas eliminar ese tratamiento especial de Consolas.

Tengo el mismo problema, pero solo si intento usar consolas. probablemente @ SteveL-MSFT tiene razón.
Probé Lucida Console y funciona bien. Entonces, ¿supongo que a Consolas le faltan algunos glifos para utf-8 (mi página de códigos)?
Powershell Core 7 funciona bien con todas las fuentes.

Increíble, compré una computadora portátil con Windows en 2020 (xps15) y tengo el mismo problema. Probablemente cientos de actualizaciones de Windows más tarde, y el problema persiste. Si PS Core era el futuro en 2019, ¿por qué no se instala en 2020? El PS Core podría ser el predeterminado, y tal vez el PS antiguo podría instalarse como respaldo en caso de que alguien necesite un problema de compatibilidad. De todos modos, instalé el Terminal de Windows y probémoslo.

@marcelomgarcia FWIW, la razón por la que PowerShell 7 no está instalado en Windows de forma predeterminada se debe a problemas de soporte y responsabilidad. Windows y PowerShell 7 tienen soporte diferente y, por lo que yo sé, los abogados no han descubierto la manera de hacerlo. Por ahora, de todos modos. Estoy seguro de que a todos les encantaría ver PowerShell 7 enviado dentro de Windows 10 o Windows Server.

Recuerde: Windows PowerShell es un componente central de Windows 10 y el instalador predeterminado lo agrega a su instalado en su computadora portátil. Es un componente FWIW totalmente compatible. Sin embargo, si desea PowerShell 7, es un proceso de instalación independiente y no integrado.

¿Qué idioma es tu computadora?

Gracias por la explicación @doctordns. Es un problema algo frustrante, y para alguien de afuera parece ser un problema "simple". Estoy instalando PowerShell 7.

Yo uso el inglés de EE. UU.