Terminal: Windows 10 1809 / 19H1 / 20H1 interrompt les paramètres de la console de Powershell. Continue de s'ouvrir avec les polices raster.

La même chose ne m'arrive que lorsque j'utilise la police Consolas. Si j'utilise autre chose - Courier New, Lucida Console, etc. - les paramètres sont conservés.

@ 50Wliu Je peux confirmer ce comportement. Consolas réinitialise la police raster. La console Lucida reste la console Lucida.

Je suis presque certain que cela a à voir avec le fait que la nouvelle version de PSReadline utilise la page de codes UTF8 pour afficher son invite, et quand elle le fait, la console essaie de recalculer la police.

Je pensais que nous avions eu des problèmes de suivi auparavant, mais je n'arrive pas à les trouver. @bitcrazed vous souvenez-vous où ils étaient? Ou était-ce un fil de discussion interne avec @lzybkr et @ SteveL-MSFT?

Quelqu'un peut-il fournir une reproduction exacte? Comme quelle police définissez-vous pour le raccourci. Sur quelle police est-il défini?

• Win-R et exécutez powershell .
• Cela commence par une police raster.
• Allez dans les paramètres et définissez la police sur Consolas. Cliquez sur OK.
• Consolas est appliqué.
• Fermez Powershell.
• Rouvrez PowerShell comme avant.
• La police est à nouveau une police raster.
• Accédez aux paramètres par défaut et définissez la police sur Consolas. Cliquez sur OK.
• Fermez Powershell.
• Rouvrez PowerShell comme avant.
• La police est à nouveau une police raster.

Je ne pense pas que ce soit même la faute de Powershell. J'ai une note quelque part ici, selon laquelle l'un des cadres .NET les plus récents (quelque chose de 4.7) décide soudainement d'utiliser 65001 comme page de code par défaut pour toutes les applications et quand cela bascule avec d'autres outils et pages de codes au démarrage et exit, nous recalculons la police.

J'ai un bug sur moi pour essayer de rendre cela moins douloureux, mais c'est vraiment le basculement soudain entre les pages de codes qui fait que c'est un problème.

Je ne peux pas reproduire cela ici. Windows PowerShell et Powershell démarrent tous deux dans la police que j'ai définie.

@Borkason Avez-vous essayé concfg clean
https://github.com/lukesampson/concfg

@borakson - Quels paramètres régionaux votre Windows est-il configuré pour utiliser?

@bitcrazed Je ne suis pas @Borkason, mais comme je rencontre ce problème, je répondrai également.

Ma langue d'affichage est l'espagnol (Espagne), tout comme mon format régional. La langue des programmes qui ne prennent pas en charge Unicode est l'anglais (États-Unis) et j'ai coché la case beta pour UTF-8 Unicode. (J'espère que c'est ce que vous cherchez ... faites-moi savoir si vous demandiez autre chose)

@bitcrazed allemand. Et j'ai mis à niveau à partir de 1803. J'ai oublié de dire cela.

@doctordns quelle police?

@doctordns quelle police?

J'utilise Lucida Console (18 pt). Mais j'en ai testé d'autres et ils fonctionnent aussi après un redémarrage de Windows PowerShell.

La même chose ne m'arrive que lorsque j'utilise la police Consolas. Si j'utilise autre chose - Courier New, Lucida Console, etc. - les paramètres sont conservés.

Cela a probablement été corrigé par les travaux récents de @lzybkr : https://github.com/lzybkr/PSReadLine/issues/542

@Borkason & @doctordns - pouvez-vous s'il vous plaît confirmer et fermer si corrigé?

Merci.

@bitcrazed, il semble que le problème sache, il est inclus dans la version de PSReadLine fournie avec 1809. En outre, ce problème se produit toujours pour moi à partir de la version 18277 de Windows Insiders.

@bitcrazed C'est un an de plus que la version 1809. Je n'appellerais pas cela «récent».

Et pour moi, rien n'a changé. Je suis sur Windows 10 build 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

Mais comme @ 50Wliu l'a déjà dit, ce n'est même pas corrigé dans l'aperçu actuel.

Voici un lien vers les commentaires: https://aka.ms/AA37kk1

@bitcrazed lié au problème qui a causé le problème.

Le correctif est dans ce PR: https://github.com/lzybkr/PSReadLine/pull/771

C'est suffisant. Est-il connu avec quelle version le correctif sera livré?

J'essaierai de publier une autre version bêta de la galerie PowerShell avant la fin de l'année, mais je ne connais pas Windows (je ne travaille pas sous Windows).

@ SteveL-MSFT possède les bits livrés dans Windows, alors peut-être qu'il peut commenter.

Valeur du nom
---- -----
PSVersion 5.1.17763.134
Bureau PSEdition
Versions compatibles PSC {1.0, 2.0, 3.0, 4.0 ...}
BuildVersion 10.0.17763.134
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SérialisationVersion 1.1.0.1

pareil ici ... prêt à réinstaller windows, VRAIMENT douloureux!

Ce problème semble lié aux polices. J'ai eu le problème dans Powershell avec Windows (cmd et Powershell core n'ont pas ce problème) lorsque je définis la police comme «Console», mais lorsque je change la police comme «Sarasa Mono SC», tout fonctionne parfaitement. J'utilise «Sarasa Mono SC» pour afficher le caractère UTF-8, Windows 10 n'a pas de police par défaut pouvant afficher suffisamment de caractères UTF-8.

Pareil ici. Mon ordinateur Surface et mon ordinateur de bureau.

Étrangement, je pense que je rencontre le même problème mais d'une manière différente. Chaque fois qu'un sous-processus est ouvert pour exécuter powershell.exe, la police de la console devient raster à partir de Consolas.

Exemple 1: J'ai vim en cours d'exécution (WSL) et il exécute une sous-commande PowerShell pour obtenir le presse-papiers du système. Chaque fois que j'exécute cette commande, elle réinitialise la police de la console aux polices raster.

Exemple 2: J'ai un script shell qui exécute PowerShell en tant que sous-processus pour obtenir les serveurs de noms système. Cela provoque la même chose pour la console, un passage aux polices raster. Rien n'est sorti vers la console. Tout se passe dans le sous-processus.

La partie vraiment étrange est que si je lance PowerShell manuellement à partir de la console (WSL), alors tout va bien et la police ne change pas.

@bitcrazed , @ SteveL-MSFT, @lzybkr : J'ai une bonne repro minimale. Cela a commencé juste après la mise à niveau de la machine vers Windows 1809. J'avais réglé la police et la console CP avant, comme ci-dessous, respectivement sur Consolas et 65001, et tout fonctionnait très bien. Je travaille avec des fichiers UTF-8, donc le CP 65001 a été essentiel pour moi. Mon environnement local est tout à fait ancien en-US, en anglais Windows 10 x64 Pro, et le CP OEM est le 437 par défaut.

1. Définissez les clés de registre suivantes (enregistrez-les sous .reg et importez). Pour une raison quelconque, il est important de changer FontFamily, car la valeur par défaut peut être différente et la police ne sera pas appliquée.

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 ENTRER . La console démarre avec la police et la page de codes correctes. Tapez chcp ; il affiche 65001 (sinon, lancez chcp 65001 ).
2. dans la console, tapez powershell -noprof ('-noprof' pour confirmer que le problème n'est pas lié à tout ce que je charge dans mon profil).

Au démarrage de PowerShell, la police de la console se transforme immédiatement en police raster et la fenêtre se redimensionne pour s'adapter. La police raster sélectionnée est Terminal, et n'a même pas de caractères WGL4 (pas de cyrillique ou de grec). C'est donc certainement un bug.

Le comportement se reproduit même si vous exécutez une commande non interactive, il est donc assez douteux que le bogue soit lié à PSReadLine:

powershell -noprof -nonint -command "echo foo"

En outre, la police de la console change de la même manière (essentiellement, la console s'ouvre dans une police raster) si PowerShell est exécuté via un raccourci, ou à partir de la boîte de dialogue Win + R, ou en double-cliquant dans l'Explorateur.

Aussi, quelques points négatifs. La police n'est pas modifiée si:

• J'exécute chcp 437 avant d'appeler powershell depuis cmd.
• La police de la console est définie dans le registre sur "Lucida Console" (tout le reste reste le même que ci-dessus). Le fait que cette police soit en quelque sorte "spéciale" a déjà été noté dans les commentaires de ce ticket.

Le thème commun dans les commentaires de ce numéro a été, je crois, un lieu européen non américain (l'allemand et l'espagnol ont été mentionnés). J'ai donc essayé ce qui suit:

1. Démarrez cmd.exe
2. Définissez la page de code de la console avec chcp NNN (voir ci-dessous):
3. Exécutez powershell -noprof .

• Avec NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - aucun changement de police
• Avec NNN = 65001, 858 et non-WGL4 hébreu 862, arabe 864 - la police change.

Qu'est-ce qui distingue le CP 858? Je suppose que c'est peut-être la clé. Le nom du CP est "OEM Multilingual Latin 1 + Euro symbol".

A noter également que chcp 1255 et chcp 1266 (hébreu et arabe) changent la police en "Courier New" même dans cmd.exe . Donc, PowerShell n'est peut-être qu'en quelque sorte plus vulnérable, pas le principal coupable?

Informations sur la version obligatoire:

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

De plus, je devrais mentionner, bien que cela ne soit probablement pas pertinent: j'ai un écran haute résolution avec une échelle d'affichage réglée à 150%.

@ kkm000 Cela a été corrigé dans PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771), mais ne fait pas partie de la version de Windows que vous utilisez, bien que le correctif ait été archivé dans une version plus récente de Windows. Je pense que la dernière version bêta publique de PSReadLine a le correctif, vous pouvez donc l'installer dans Windows PowerShell en utilisant:

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

S'il se plaint que -AllowPrerelease n'est pas trouvé, vous devrez mettre à jour PowerShellGet:

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

bien que le correctif ait été archivé dans une version plus récente de Windows.

Cela signifie-t-il que le correctif sera disponible dans une future version (19H1) Insiders?

@ 50Wliu oui

@ SteveL-MSFT j'ai la même version que @ kkm000 , je vous ai exécuté des commandes et je ne travaille pas pour moi, je rate quelque chose?

@ SteveL-MSFT Je trouve très décevant que cela ne puisse pas être livré avec une mise à jour Windows régulière. Si Microsoft rompt quelque chose avec une mise à jour, il est de leur responsabilité de le réparer avec une mise à jour et de ne pas le reporter de plus de six mois et de prévoir de l'expédier avec la prochaine version de Windows, ou de demander aux gens de sauter à travers les cerceaux pour obtenir un correctif d'un pré- dépôt de

alors ... j'ai dû exécuter cette commande plus d'une fois

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

avec PowerShell fonctionnant en tant qu'administrateur, taskmgr pour tuer PowerShell, puis recommencez car il a échoué deux ou trois fois. Et… on dirait que ça marche! Les paramètres d'affichage personnalisés de mon $ PROFILE se comportent désormais comme avant la mise à niveau.

Cela vient de commencer à m'arriver après la mise à niveau vers la dernière version 1809 17763.292 de la précédente mise à jour cumulative 1809 . J'ai suivi les instructions pour installer le nouveau PSReadLine et il semble y en avoir:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
j'ai

PSVersion 5.1.17763.134

La police Consolas est remplacée par des polices raster.

METTRE À JOUR

cela semble être une solution instable. Maintenant, après le redémarrage, le correctif tient / fonctionne, quel que soit le niveau d'exécution.

Un comportement intéressant que je vois maintenant. Après avoir exécuté le «correctif» sur mon ordinateur portable
Valeur du nom
---- -----
PSVersion 5.1.17763.134
Bureau PSEdition
Versions compatibles PSC {1.0, 2.0, 3.0, 4.0 ...}
BuildVersion 10.0.17763.134
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SérialisationVersion 1.1.0.1

lors de l'exécution de PS en mode utilisateur, le correctif est très bien; lors de l'exécution de PS en tant qu'administrateur, le correctif ne fonctionne pas.

Cela ne fonctionne pas pour moi même en mode utilisateur.

@ SteveL-MSFT, il semble que le correctif ne fonctionne pas pour moi. De plus, il ne semble pas que le module d'installation ait changé quoi que ce soit. J'ai déjà un assez dernier PowerShellGet ( -AllowPrerelease fonctionne certainement; mes raccourcis clavier dépendent d'un PSReadLine récent). J'ai initialement installé PSReadLine il y a quelques mois (avant la mise à niveau de Windows!), Donc je m'attendais à ce que je reçoive une mise à niveau aujourd'hui avec votre commande suggérée, mais je ne sais pas comment confirmer si quelque chose a en fait été changé. S'il te plait peux-tu aider? J'ai pris la version de PSReadLine avant de tenter la mise à niveau:

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

Ensuite, j'ai mis à jour, comme vous l'avez suggéré:

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

Le Install-Module tourné pendant un moment, et une barre de progression avec la piqûre de 'o est striée en haut de l'écran. Je ne pense pas que cela signifie quoi que ce soit, mais la répétition du module d'installation fait également apparaître la barre de progression pendant un bref instant. Mais la nouvelle console souffre toujours du problème d'origine. De plus, je ne vois aucun changement ici, peut-être pourriez-vous repérer quelque chose? Je peux certainement regarder les versions de fichiers, etc. que j'ai, je ne sais pas quoi chercher.

Cela n'a rien fait non plus:

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

Dans la nouvelle console, le nouveau (?) PSReadLine semble identique:

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

De plus, en raison des commentaires @ mjoyce6500 et @wigster ci-dessus, j'ai vérifié la console utilisateur (non-admin), et elle montre également le bogue comme avant.

S'il vous plaît, j'apprécierai toute aide / pensées que vous pourriez partager!

@ SteveL-MSFT, @lzybkr , je ne pense pas qu'il y ait une mise à jour dans PSGallery. La dernière version bêta avait été publiée un mois avant la fusion du numéro 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

Malheureusement, il n'inclut plus ReleaseNotes, comme le faisait beta2. Mais le timing exclut certainement cette possibilité.

Note sans rapport, l'auteur et la société sont apparemment échangés:

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

Author      : Microsoft Corporation
CompanyName : lzybkr

Le «correctif» a toujours des résultats mitigés pour moi. Powershell en mode utilisateur fonctionne correctement, aucune modification de mes couleurs / polices personnalisées après l'exécution de la commande indiquée ci-dessus. Bien que Powershell en mode Admin ne soit pas corrigé, montre le comportement noté dans ce bogue.

@ mjoyce6500 pouvez-vous me donner les étapes de repro exactes? Notez également la version de Windows et de PSReadLine que vous utilisez. Merci.

@ SteveL-MSFT, pourriez-vous jeter un œil à mon commentaire ci - trouve même pas la version mise à jour de PSReadLine dans PSGallery, alors que d'autres personnes rapportent des «résultats mitigés». À l'heure actuelle, la version la plus élevée disponible est toujours PSReadLine 2.0.0-beta3 18-09-04 21:59:13 , publiée un mois avant la fusion du correctif.

De plus, comment connaître la version que j'utilise? Sur une autre machine, où je n'ai jamais tenté votre suggestion de mise à jour, en vérifiant la première ligne du fichier Changes.txt du package installé:

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

Ensuite, Install-Module tente en effet d'installer 2.0.0-beta3, confirmez en exécutant sans -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'.

Est-il possible que je reçoive la mise à jour pas d'un endroit où d'autres personnes le font?

Après la mise à jour, le fichier Changes.txt a un en-tête 2.0.0-beta3 comme première ligne:

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

Et la même reproduction qu'avant, console d'administration ou pas. Depuis la console cmd.exe avec la police 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>

Bien sûr, je ne m'attends pas à ce que cela fonctionne, car je n'ai pas la DLL mise à jour. Ma question est de savoir comment il est possible que d'autres personnes en aient.

Avoir le même problème ici, et le correctif ci-dessus n'a eu aucun effet.

La façon dont le correctif a fonctionné (au moins partiellement) pour la minorité de personnes est toujours ahurissante, étant donné qu'elle n'a jamais été publiée, en regardant de derrière cette paire d'yeux. Dire que je suis déconcerté, c'est ne rien dire. Ma pensée actuelle est qu'il existe DEUX galeries PS, et le correctif a été publié dans l'une d'entre elles à laquelle seules quelques personnes accèdent.

@ kkm000 Il existe une PSGallery et beta.3 est la dernière PSReadLine publiée. La version de PSReadLine 2.0.0 livrée dans Win10 est un fork de PSReadLine 2.0.0 avec quelques correctifs spécifiques plus récents, donc en ce sens, elle est en avance sur celle publiée sur PSGallery.

@ SteveL-MSFT
J'ai installé beta3 et rien n'est résolu.
Les deux avec Windows 1809 et 1903 (Build 18334.1)

@Borkason, le correctif pour ne pas changer la police si vous n'utilisez pas de police raster devrait déjà être dans cette version. Quelle police utilisez-vous?

J'utilise Consolas. Il bascule après chaque redémarrage du PowerShell.

@Borkason quelle locale utilisez-vous? en-US ou autre chose?

de-DE

Cela fonctionne soudainement maintenant. Cela m'a pris comme 10 fois de fermer et d'ouvrir le PowerShell, mais maintenant il semble coller.

Il s'est encore cassé. Donc, apparemment, il décide au hasard de se briser à nouveau, ou de travailler. 💢

Je l'ai fait avec 18334 - complètement au hasard. Cela ne s'est pas reproduit.

D'accord, la différence est que lorsque j'exécute PowerShell via ALT-R, la police reste la même. Lorsque je l'exécute à partir du menu Démarrer, il réinitialise la police en raster, même lorsque je l'ai changée en consolas lors de la session précédente que j'ai exécutée à partir du menu Démarrer.

(Et par menu Démarrer, je veux dire en fait que j'appuie sur la touche Windows du clavier, puis que je tape `` PowerShell '' et que j'appuie sur Entrée.)

@ SteveL-MSFT - Je n'ai pas publié de version avec le correctif de police dans la galerie PowerShell. Le correctif est disponible dans le référentiel PSReadLine, vous pouvez donc le créer vous-même ou récupérer une version d'AppVeyor.

@Borkason - Si vous utilisez Consolas je pense que vous ne devriez pas voir le bogue de police.

Il reste difficile de définir les paramètres par défaut de la console en raison de la rétrocompatibilité. Les valeurs par défaut peuvent être définies dans le registre (par application console) ou dans le raccourci utilisé pour démarrer l'application console. Je sais que l'équipe de la console veut résoudre ce problème, mais c'est apparemment un problème difficile.

Si vous utilisez Consolas je pense que vous ne devriez pas voir le bogue de police.

Ensuite, ce bogue n'est pas résolu, car j'utilise Consolas et le raccourci le fait aussi.

Il reste difficile de définir les paramètres par défaut de la console en raison de la rétrocompatibilité.

Ensuite, Microsoft devrait fournir un script / outil FixIt pour ceux qui veulent simplement que leur console fonctionne à nouveau, quelle que soit la compatibilité ascendante ...

Je sais que l'équipe de la console veut résoudre ce problème, mais c'est apparemment un problème difficile.

Apparemment. Et il est évidemment aussi extrêmement difficile de mettre le fichu demi-correctif PowerShell en 1809, sans parler de 1903 ...

😠

Je viens de mettre à jour vers 18342 et le problème semble être résolu (18334 est toujours réinitialisé aux polices raster à chaque fois).

Je suis toujours d'accord pour dire que le correctif devrait être rétroporté à 1809.

EDIT: Problème de configuration incorrecte lors de la mise à niveau (voir https://github.com/Microsoft/console/issues/280#issuecomment-474917761). Le bogue n'est toujours pas corrigé.

Je viens de faire une nouvelle installation de 20H1. Le problème est toujours là. 🤣 C'est une blague, non?

Cela peut être résolu en installant les outils Rsat 1809 Windows 10.
Vous ne pouvez pas installer RSAT sur des ordinateurs exécutant les éditions Familiale ou Standard de Windows.
Vous ne pouvez installer RSAT que sur les éditions Windows 10 Professionnel ou Entreprise.

Méthode 1 - Utilisation de l'ajout d'une fonctionnalité Installez les outils RSAT sur Windows 10 version 1809

Pour installer les outils RSAT sur Windows 10 version 1809, cliquez sur Démarrer. Cliquez sur Paramètres et sur la page des paramètres, cliquez sur Applications.
Dans le volet droit, sous Applications et fonctionnalités, cliquez sur Gérer les fonctionnalités facultatives.
Cliquez maintenant sur + Ajouter une fonctionnalité.Attendez que la liste des fonctionnalités soit remplie.
Faites défiler vers le bas jusqu'à ce que vous voyiez les fonctionnalités RSAT.
Sélectionnez à présent l'une des fonctionnalités RSAT que vous souhaitez installer. Dans ce cas, je sélectionne RSAT: fonctionnalité d'outils de gestion de stratégie de groupe.
Cliquez sur Installer.
Cliquez sur l'icône de retour et attendez que la fonction soit installée.
Vous devriez maintenant trouver les outils de gestion des stratégies de groupe sous Démarrer> Outils d'administration Windows.

fonctionne sited .... Installez RSAT Tools sur Windows 10 version 1809 et ultérieure
Par Prajwal Desai Dernière mise à jour le 31 janvier 2019

J'espère que cela t'aides....

@RobRoberson, vous comprenez vraiment ce que vous dites, non?

J'ai le même problème sur Windows 1809 17763.316.
zh_Hans_CN avec l'option UTF-8 activée.

Les versions d'aperçu résoudront-elles le problème?

Les versions d'aperçu résoudront-elles le problème?

Non.

Je reprends ce que j'ai dit dans https://github.com/Microsoft/console/issues/280#issuecomment -465837677. Ce qui s'est réellement passé, c'est que tous mes paramètres de langue ont été réinitialisés, ce qui a désactivé la page de codes 65001. Je viens de m'en rendre compte aujourd'hui, je l'ai réactivé et ... bonjour les polices raster.

@ SteveL-MSFT ce commentaire de votre part semble incorrect par le nombre de personnes qui disent encore que ce problème n'est pas résolu, même sur les dernières versions d'Insider (je suis actuellement sur 18361, par exemple).

J'adorerais une solution à ce sujet. Vraiment comme Consolas pour le développement sous Windows.

L'utilisation de la version interne de Microsoft 1903 peut confirmer que ce bogue existe toujours pour Consolas et UFT8. La police Lucida Console fonctionne bien et sera ma solution de contournement

Nous travaillons sur une nouvelle mise à jour de PSReadLine, puis nous verrons comment l'introduire dans Windows

Sur pwsh 6.2.0, ce problème semblait avoir été résolu, mais il est revenu après avoir utilisé msbuild 2017 pour créer quoi que ce soit (la version 2015 était bien). Je ne sais pas exactement où cela se passe car c'est à partir de node-gyp , mais si des modules natifs doivent être (re) construits, ma console reviendra aux polices raster.

Heureusement, je n'ai plus besoin de réinitialiser les polices à chaque fois que j'ouvre le terminal, uniquement lors de l'exécution de node-gyp.

PSReadLine 2.0.0-beta4 a été publié et devrait résoudre de nombreux problèmes (bien qu'il en ait quelques nouveaux). https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@ SteveL-MSFT 2.0.0-beta4 n'a pas corrigé ce bogue.

J'utilise un terminal CMD régulier avec bash.exe + phpunit = même problème de git. Il apparaît après quelques secondes de démarrage du script.
Pas sûr de la raison dans PowerShell ...

@ SteveL-MSFT 2.0.0-beta4 ne résout pas non plus le bogue pour moi.

@sebgod Merci pour le tuyau, je suis passé de Consolas 16 à Lucida Console 14, c'est à peu près la même chose à mes yeux.

Je vais demander à quelqu'un de revoir ça

@ SteveL-MSFT Pour reproduire cela, ouvrez une invite de commande, définissez votre police sur Consolas,
puis exécutez cmd /c chcp 65001 >NUL && powershell

Ok, je pense avoir identifié le problème réel et cela n'a rien à voir avec PSReadLine. Il y a une vérification dans Windows PowerShell pour voir si la page de codes est prise en charge par la police Consolas. La liste est ici . UTF-8 65001 n'est pas dans cette liste, donc chaque fois que Windows PowerShell identifie une page de codes qui n'est pas prise en charge par Consolas, il changera la police en Terminal . PowerShell Core 6.x n'a plus ce code, vous ne voyez donc pas ce comportement. J'hésite à changer ce code car il pourrait casser autre chose. Pour mes propres notes, c'est dans la ligne 2648 de ConsoleControl.cs.

Ok, je pense avoir identifié le problème réel et cela n'a rien à voir avec PSReadLine. Il y a une vérification dans Windows PowerShell pour voir si la page de codes est prise en charge par la police Consolas. La liste est ici . UTF-8 65001 n'est pas dans cette liste, donc chaque fois que Windows PowerShell identifie une page de codes qui n'est pas prise en charge par Consolas, il changera la police en Terminal . PowerShell Core 6.x n'a plus ce code, vous ne voyez donc pas ce comportement. J'hésite à changer ce code car il pourrait casser autre chose. Pour mes propres notes, c'est dans la ligne 2648 de ConsoleControl.cs.

Je ne sais pas comment cela peut casser quelque chose, car UTF-8 n'était pas pris en charge avant les versions les plus récentes de Windows 10.

@sebgod casser quelque chose ici signifie un rendu incorrect car je suis sûr que Consolas n'a pas tous les glyphes nécessaires à UTF-8

@ SteveL-MSFT Lucida Console, Courier New et toutes les autres polices disponibles qui ne sont pas affectées par ce problème bien qu'elles ne prennent pas non plus en charge la page de codes 65001. Par coïncidence, Consolas prend même en charge plus de pages de codes que Lucida Console. Alors pourquoi cela n'arrive-t-il qu'avec Consolas?

Mais d'une manière générale, c'est aux utilisateurs de décider quelle police est utilisée pour l'affichage. Si les glyphes ne sont pas présents, ils sont affichés sous la forme � et l'utilisateur peut prendre la décision de changer la police.

@Borkason Je pense que c'est un problème très clair du point de vue d'un anglophone, mais il y a sans aucun doute une crainte de causer des problèmes aux utilisateurs internationaux que nous ne sommes pas en mesure de prévoir.

À titre d'exemple, lorsque @bitcrazed (un autre membre de l'équipe Microsoft Terminal) a introduit un PR à cURL qui implémenterait la prise en charge de Windows VT https://github.com/curl/curl/pull/3011 (ce qui impliquait de changer la page de codes en 65001), cela a fini par poser un problème aux utilisateurs internationaux: https://github.com/curl/curl/issues/3211

Cela nécessitait un correctif qui écrit UTF-8 dans la page de codes actuelle en utilisant des API à chaîne large à la place: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9

Cela ne me surprend pas que l'équipe Microsoft Terminal veuille aborder cela très attentivement après cela.

@sebgod casser quelque chose ici signifie un rendu incorrect car je suis sûr que Consolas n'a pas tous les glyphes nécessaires à UTF-8

OK, il n'y a pas une seule police fournie par Windows qui couvre tous les glyphes définis en UTF-8. Cmd.exe s'appuie sur une technologie appelée liaison de polices pour fournir un rendu pour tous les glyphes.
Avant l'inclusion de la définition de UTF-8 comme page de codes système, il fallait utiliser chcp 65001 manuellement, mais cela fonctionnait correctement. Le bit de liaison de police doit être effectué manuellement dans le registre pour qu'il fonctionne dans tous les cas.

@ImportTaste Je ne pense pas que cela ait quelque chose à voir avec ça. La solution de secours n'est effective que si Consolas est utilisé. Si une autre police est utilisée comme Lucida Console ou Courier New, cela ne se produit pas. Au moins, Lucida Consolas a le même support de page de code que Consolas, il est donc difficile de comprendre pourquoi cela a été fait de cette façon. S'il y avait un problème pour les utilisateurs internationaux (et au fait, je ne suis pas anglophone comme vous le supposez), cela affecterait toujours tous les utilisateurs qui n'utilisent pas Consolas.

À mon avis, le repli ne devrait pas être là en premier lieu (voir PWSH 6 + 7) ou a été implémenté de manière bâclée (pourquoi seulement Consolas?).

@ SteveL-MSFT Et je crois que le réparer n'est pas du tout un risque, car le bogue n'a été introduit qu'avec la version 1809 de Windows et apparemment c'est un changement non documenté, personne ne sait pourquoi il a été modifié.

@Borkason Comme je l'ai dit, c'était un exemple relatable d'une erreur inattendue.

Je suis surpris d'apprendre que ce n'est censé être qu'un changement de 1809, j'ai eu des problèmes avec la police de la console se changeant en raster dans le passé.

Elle n'a été détectée qu'en 1809 car la police par défaut de la console était Consolas. Avant cela, je crois que c'était Lucida Console? Et le code fonctionnait de la même manière pour cette police. Ma compréhension de ce code (qui existe depuis toujours et avant mon équipe de l'équipe PowerShell) est que dans les sources Windows, nous n'avons qu'un seul raccourci utilisé pour PowerShell et ce raccourci définit la police par défaut. Ainsi, lorsque la police par défaut a été modifiée, les utilisateurs d'Asie de l'Est se sont plaints du fait que leurs glyphes n'étaient pas rendus car la police ne la prend pas en charge. Donc, ce code détecte que la police et les paramètres régionaux ne sont pas compatibles et le remplace par celui qui sera rendu.

J'hésite à apporter des modifications à Windows PowerShell, car même des changements apparemment mineurs comme celui-ci conduisent à des régressions inattendues.

@sebgod & all: quelques petites choses ici:

Clarifications

1. Il n'y a pas de police unique sur aucune plate-forme qui inclut chaque glyphe pour chaque point de code qui peut être représenté en UTF-8.
2. Cmd.exe ne sait rien sur les polices - Cmd.exe est un shell
3. Console (ConHost.exe) fournit la traditionnelle UX de ligne de commande `` de type terminal '' dans Windows
4. Le moteur de rendu de texte actuel de la console ne prend pas en charge le remplacement des polices et ne peut pas restituer la plupart des emoji - essayez-le et vous verrez le caractère non affichable (point d'interrogation dans une boîte)

Terminal et console

Windows Terminal est notre nouveau Terminal UX de nouvelle génération. Il partage plusieurs composants communs avec la console intégrée, plus il ajoute plusieurs nouvelles fonctionnalités, y compris un tampon de texte et un moteur de rendu de texte qui peuvent / vont stocker et afficher pratiquement tous les glyphes Unicode.

Ces composants seront finalement ré-ingérés dans la console intégrée, mais pas avant que nous ayons publié le Terminal v1.0 et qu'ils aient eu le temps d'être bien testés dans le monde réel.

PowerShell

Comme le souligne @ SteveL-MSFT, PowerShell Core (PSCore) ne présente pas ce problème et puisque PSCore est l'avenir de PowerShell, nous vous encourageons à l'utiliser dans la mesure du possible.

Changer le comportement de PowerShell pour Windows (PS) est potentiellement difficile car, comme nous le savons en essayant de corriger / modifier le comportement de Cmd, même de petits changements apparemment inoffensifs peuvent entraîner une rupture surprenante dans le monde réel.

Cela dit, je discuterai avec Steve & Team et nous explorerons si PS pourrait être modifié pour choisir une police non raster (par exemple Consolas / Lucida / etc.) Pour la page de codes 65001.

@sebgod & all: quelques petites choses ici:

Clarifications

1. Il n'y a pas de police unique sur aucune plate-forme qui inclut chaque glyphe pour chaque point de code qui peut être représenté en UTF-8.

Oui, c'est pourquoi j'ai dit "il n'y a pas une seule police fournie par Windows qui couvre tous les glyphes définis en UTF-8"

1. Cmd.exe ne sait rien sur les polices - Cmd.exe est un shell

Oui, désolé d'être paresseux, je voulais simplement faire référence à ce qui se passe si vous tapez "cmd.exe" dans la zone de recherche Windows

1. Console (ConHost.exe) fournit la traditionnelle UX de ligne de commande `` de type terminal '' dans Windows
2. Le moteur de rendu de texte actuel de la console ne prend pas en charge le remplacement des polices et ne peut pas restituer la plupart des emoji - essayez-le et vous verrez le caractère non affichable (point d'interrogation dans une boîte)

D'après ce que j'ai compris, le moteur actuel ne peut restituer aucun caractère à partir de plans Unicode supérieurs, qui incluent (la plupart) des caractères emoji.

Maintenant, je dois être très pointilleux, je parlais de Font Linking, qui est pris en charge ou du moins fonctionne:

En ajoutant la valeur Lucida Console sous la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
avec le type REG_MULTI_SZ et les données suivantes (ou similaires, doivent être des polices à espacement fixe):

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

Il est possible d'afficher la plupart des glyphes de plan de base Unicode lors de l'utilisation de chcp 65001 ou depuis 1803 en définissant la page de code système sur UTF-8 (version bêta mais fonctionnant jusqu'à présent), que je préfère personnellement utiliser les pages de code spécifiques pour chaque langue car j'utilise plusieurs langues.

Maintenant, je préfère utiliser Consolas qui ne fonctionnait pas depuis 1903 en raison du passage aux polices raster.

Terminal et console

Windows Terminal est notre nouveau Terminal UX de nouvelle génération. Il partage plusieurs composants communs avec la console intégrée, plus il ajoute plusieurs nouvelles fonctionnalités, y compris un tampon de texte et un moteur de rendu de texte qui peuvent / vont stocker et afficher pratiquement tous les glyphes Unicode.

Ces composants seront finalement ré-ingérés dans la console intégrée, mais pas avant que nous ayons publié le Terminal v1.0 et qu'ils aient eu le temps d'être bien testés dans le monde réel.

Oui j'ai déjà utilisé le nouveau Terminal UX et il est bien sûr extrêmement agréable à utiliser, mais il ne permet pas de saisir des caractères chinois pour le moment (j'espère que cela sera corrigé éventuellement)

PowerShell

Comme le souligne @ SteveL-MSFT, PowerShell Core (PSCore) ne présente pas ce problème et puisque PSCore est l'avenir de PowerShell, nous vous encourageons à l'utiliser dans la mesure du possible.

Changer le comportement de PowerShell pour Windows (PS) est potentiellement difficile car, comme nous le savons en essayant de corriger / modifier le comportement de Cmd, même de petits changements apparemment inoffensifs peuvent entraîner une rupture surprenante dans le monde réel.

Cela dit, je discuterai avec Steve & Team et nous explorerons si PS pourrait être modifié pour choisir une police non raster (par exemple Consolas / Lucida / etc.) Pour la page de codes 65001.

Si les changements peuvent casser quelque chose et que nous ne pouvons même pas savoir quoi exactement, donc rien ne peut plus jamais être changé dans le terminal?

J'ai "résolu" le problème en utilisant Powershell Core. J'ai d'abord remarqué qu'aucun des paramètres Powershell ne fait quoi que ce soit (mais cela a changé les paramètres sur cmd.exe). Après quelques heures à essayer différentes choses, je suis tombé sur Powershell Core et dès que je l'ai téléchargé, les paramètres que j'avais enregistrés auparavant ont pris effet dès que j'ai ouvert l'aperçu du noyau Powershell.

Vous avez le même problème lors de l'exécution de certaines commandes (y compris scoop) à partir du gestionnaire FAR - cet effet ruine simplement la façon dont FAR est affiché. Se produit uniquement avec la police Consolas et l'option bêta activées pour utiliser la page de codes UTF-8 (65001) dans la console. Ma langue est le russe.

En tant qu'utilisateur final - C'est vraiment ennuyeux quand le programme essaie d'être plus intelligent que moi. Je peux vivre avec des points d'interrogation au lieu de certains symboles UTF-8, mais ce changement de police ne fait que ruiner l'affichage des programmes qui ne devraient pas être affectés du tout, comme FAR Manager. C'est une douleur.

Pour l'instant, j'ai dû revenir à la langue russe pour la console (de retour de UTF-8), mais cela limite le travail avec des fichiers nommés en utilisant des symboles d'autres paramètres régionaux. J'espère que vous pourrez supprimer ce traitement spécial Consolas.

J'ai le même problème mais seulement si j'essaye d'utiliser des consolas. probablement @ SteveL-MSFT a raison.
J'ai essayé Lucida Console et cela fonctionne bien. Donc je suppose que Consolas manque des glyphes pour utf-8 (ma page de codes)?!
Powershell Core 7 fonctionne bien avec toutes les polices.

Incroyable, j'ai acheté un ordinateur portable Windows en 2020 (xps15) et j'ai le même problème. Probablement des centaines de mises à jour Windows plus tard, et le problème persiste. Si PS Core était l'avenir en 2019, pourquoi n'est-il pas installé en 2020? Le PS Core pourrait être par défaut, et peut-être que l'ancien PS pourrait être installé comme solution de secours au cas où quelqu'un aurait besoin d'un problème de compatibilité. Quoi qu'il en soit, j'ai installé le terminal Windows et essayons-le.

@marcelomgarcia FWIW, la raison pour laquelle PowerShell 7 n'est pas installé par défaut dans Windows est due à des problèmes de support et de responsabilité. Windows et PowerShell 7 ont un support différent et pour autant que je sache, les avocats n'ont pas trouvé de moyen de le faire. Pour l'instant, en tout cas. Je suis sûr que tout le monde aimerait voir PowerShell 7 intégré à Windows 10 ou Windows Server.

Rember: Windows PowerShell est un composant principal de Windows 10 et le programme d'installation par défaut l'ajoute à votre installation sur votre ordinateur portable. C'est un composant FWIW entièrement pris en charge. Cependant, si vous voulez PowerShell 7, il s'agit d'un processus d'installation séparé et non intégré.

Quelle est la langue de votre ordinateur?

Merci pour l'explication @doctordns. C'est juste un problème quelque peu frustrant, et pour quelqu'un de l'extérieur semble être un problème «simple». J'installe PowerShell 7.

J'utilise l'anglais américain.