Terminal: Windows 10 1809 / 19H1 / 20H1 bricht die Konsoleneinstellungen von Powershell. Öffnet weiterhin mit Raster-Schriftarten.

Das gleiche passiert mir nur, wenn ich die Consolas-Schriftart verwende. Wenn ich etwas anderes verwende - Courier New, Lucida Console usw. - bleiben die Einstellungen erhalten.

@ 50Wliu Ich kann dieses Verhalten bestätigen. Consolas wird auf die Rasterschrift zurückgesetzt. Lucida Console bleibt Lucida Console.

Ich bin mir fast sicher, dass dies damit zu tun hat, dass die neue Version von PSReadline die UTF8-Codepage zum Anzeigen der Eingabeaufforderung verwendet. In diesem Fall versucht die Konsole, die Schriftart neu zu berechnen.

Ich dachte, wir hätten zuvor einige Probleme, aber ich kann sie anscheinend nicht finden. @bitcrazed erinnerst du dich, wo sie waren? Oder war es ein interner Mail-Thread mit @lzybkr und @ SteveL-MSFT?

Kann jemand einen genauen Repro liefern? Zum Beispiel, welche Schriftart Sie auf die Verknüpfung einstellen. Auf welche Schriftart wird es eingestellt?

• Win-R und führen Sie powershell .
• Es beginnt mit der Rasterschrift.
• Gehen Sie in die Einstellungen und stellen Sie die Schriftart auf Consolas ein. OK klicken.
• Konsolen werden angewendet.
• Powershell schließen.
• Öffnen Sie die Powershell wie zuvor.
• Schriftart ist wieder Rasterschrift.
• Gehen Sie in die Standardeinstellungen und stellen Sie die Schriftart auf Consolas ein. OK klicken.
• Powershell schließen.
• Öffnen Sie die Powershell wie zuvor.
• Schriftart ist wieder Rasterschrift.

Ich glaube nicht, dass dies sogar Powershells Schuld war. Ich habe hier irgendwo eine Notiz, dass eines der neuesten .NET Frameworks (4.7something) plötzlich beschließt, 65001 als Standardcodepage für alle Apps zu verwenden, und wenn dies beim Start und mit anderen Tools und Codepages hin und her wechselt Beenden, wir berechnen die Schriftart neu.

Ich habe einen Fehler bei mir, um zu versuchen, das weniger schmerzhaft zu machen, aber es ist wirklich das plötzliche Umschalten zwischen den Codepages, das dies zu einem Problem macht.

Ich kann das hier nicht reproduzieren. Sowohl Windows PowerShell als auch Powershell werden in der von mir festgelegten Schriftart gestartet.

@Borkason Haben Sie concfg clean ausprobiert ?
https://github.com/lukesampson/concfg

@borakson - Für welches Gebietsschema ist Ihr Windows konfiguriert?

@bitcrazed Ich bin nicht @Borkason, aber da ich dieses Problem habe, werde ich auch antworten.

Meine Anzeigesprache ist Spanisch (Spanien), ebenso wie mein regionales Format. Die Sprache für Programme, die Unicode nicht unterstützen, ist Englisch (USA), und ich habe das Beta-Kontrollkästchen für UTF-8 Unicode aktiviert. (Hoffe, das ist es, wonach du suchst ... lass es mich wissen, wenn du nach etwas anderem fragst)

@bitcrazed Deutsch. Und ich habe ein Upgrade von 1803 durchgeführt.

@doctordns welche Schriftart?

@doctordns welche Schriftart?

Ich benutze Lucida Console (18 pt). Aber ich habe andere getestet und sie funktionieren auch nach einem Neustart von Windows PowerShell.

Das gleiche passiert mir nur, wenn ich die Consolas-Schriftart verwende. Wenn ich etwas anderes verwende - Courier New, Lucida Console usw. - bleiben die Einstellungen erhalten.

Dies wurde wahrscheinlich durch die jüngste Arbeit von @lzybkr behoben: https://github.com/lzybkr/PSReadLine/issues/542

@Borkason & @doctordns - können Sie bitte bestätigen und schließen, wenn dies behoben ist?

Vielen Dank.

@bitcrazed Es sieht so aus, als ob das Problem, auf das Sie verweisen, bereits 2017 behoben wurde und soweit ich das beurteilen kann, in der Version von PSReadLine enthalten ist, mit der 1809 ausgeliefert wird. Darüber hinaus tritt dieses Problem bei mir ab Windows Insiders Build 18277 immer noch auf.

@bitcrazed Das ist ein Jahr älter als die Veröffentlichung von 1809. Ich würde das nicht "neu" nennen.

Und für mich hat sich nichts geändert. Ich bin auf 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

Aber wie @ 50Wliu bereits sagte, ist es in der aktuellen Vorschau nicht einmal behoben.

Hier ist ein Link zum Feedback: https://aka.ms/AA37kk1

@bitcrazed im Zusammenhang mit dem Problem, das das Problem verursacht hat.

Das Update finden Sie in dieser PR: https://github.com/lzybkr/PSReadLine/pull/771

Fair genug. Ist bekannt, mit welchem ​​Build das Update ausgeliefert wird?

Ich werde versuchen, vor Ende des Jahres eine weitere Beta für die PowerShell-Galerie zu veröffentlichen, aber ich weiß nichts über Windows (ich arbeite nicht unter Windows).

@ SteveL-MSFT besitzt die Bits, die in Windows geliefert werden, also kann er vielleicht einen Kommentar abgeben.

Name Wert
---- -----
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

Gleiches hier ... bereit, Windows neu zu installieren, WIRKLICH schmerzhaft!

Dieses Problem scheint Links zu Schriftarten zu sein. Ich habe das Problem in Powershell mit Windows (cmd und Powershell Core haben dieses Problem nicht), wenn ich die Schriftart als "Konsole" festgelegt habe, aber wenn ich die Schriftart als "Sarasa Mono SC" ändere, funktionieren alle einwandfrei. Ich verwende 'Sarasa Mono SC', um UTF-8-Zeichen anzuzeigen. Windows 10 hat keine Standardschriftart und kann genügend UTF-8-Zeichen anzeigen.

Hier gilt das gleiche. Sowohl mein Surface- als auch mein Desktop-PC.

Seltsamerweise denke ich, dass ich das gleiche Problem habe, aber auf eine andere Art und Weise. Immer wenn ein Unterprozess zum Ausführen von Powershell.exe geöffnet wird, ändert sich die Konsolenschriftart von Consolas in Raster.

Beispiel 1: Ich habe vim running (WSL) und es wird ein Powershell-Unterbefehl ausgeführt, um die System-Zwischenablage abzurufen. Jedes Mal, wenn ich diesen Befehl ausführe, wird die Konsolenschriftart auf Rasterschriftarten zurückgesetzt.

Beispiel 2: Ich habe ein Shell-Skript, das Powershell als Unterprozess ausführt, um die System-Nameserver abzurufen. Dies bewirkt dasselbe mit der Konsole, einem Wechsel zu Raster-Schriftarten. Es wird nichts an die Konsole ausgegeben. Alles passiert im Unterprozess.

Der wirklich seltsame Teil ist, dass wenn ich Powershell manuell von der Konsole (WSL) aus starte, es in Ordnung ist und sich die Schriftart nicht ändert.

@bitcrazed , @ SteveL-MSFT, @lzybkr : Ich habe einen guten minimalen Repro. Dies begann direkt nach dem Upgrade des Computers auf Windows 1809. Ich hatte zuvor die Schriftart und den Konsolen-CP wie unten auf Consolas bzw. 65001 eingestellt, und alles funktionierte einwandfrei. Ich arbeite mit UTF-8-Dateien, daher war der CP 65001 für mich von wesentlicher Bedeutung. Mein Gebietsschema ist normales altes US-amerikanisches Windows 10 x 64 Pro in englischer Sprache, und der OEM-CP ist die Standardeinstellung 437.

1. Legen Sie die folgenden Registrierungsschlüssel fest (als .reg speichern und importieren). Aus irgendeinem Grund ist es wichtig, FontFamily zu ändern, da die Standardeinstellung möglicherweise anders ist und die Schriftart nicht angewendet wird.

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. Gewinnen Sie + R cmd.exe ENTER . Die Konsole beginnt mit der richtigen Schriftart und Codepage. Geben Sie chcp . Es wird 65001 gedruckt (falls nicht, führen Sie chcp 65001 ).
2. Geben Sie in die Konsole powershell -noprof ('-noprof' ein, um zu bestätigen, dass das Problem nicht mit etwas zusammenhängt, das ich in mein Profil lade).

Beim Start von PowerShell ändert sich die Konsolenschrift sofort in eine Rasterschrift, und die Größe des Fensters wird entsprechend angepasst. Die ausgewählte Rasterschrift ist Terminal und enthält nicht einmal WGL4-Zeichen (kein Kyrillisch oder Griechisch). Das ist also sicherlich ein Fehler.

Das Verhalten wird auch dann reproduziert, wenn ein nicht interaktiver Befehl ausgeführt wird. Daher ist es eher zweifelhaft, ob der Fehler mit PSReadLine zusammenhängt:

powershell -noprof -nonint -command "echo foo"

Außerdem ändert sich die Konsolenschriftart auf ähnliche Weise (im Wesentlichen wird die Konsole in einer Rasterschriftart geöffnet), wenn PowerShell über eine Verknüpfung oder über das Dialogfeld Win + R oder durch Doppelklicken im Explorer ausgeführt wird.

Auch einige Negative. Die Schriftart wird nicht geändert, wenn:

• Ich führe chcp 437 bevor ich powershell von cmd aus aufrufe.
• Die Konsolenschriftart ist in der Registrierung auf "Lucida Console" eingestellt (alles andere bleibt wie oben). Dass diese Schriftart irgendwie "besonders" ist, wurde bereits in den Kommentaren in diesem Ticket vermerkt.

Das gemeinsame Thema in den Kommentaren in dieser Ausgabe war meines Erachtens ein nicht in den USA ansässiges europäisches Gebietsschema (Deutsch und Spanisch wurden erwähnt). Also habe ich folgendes versucht:

1. Starten Sie cmd.exe
2. Stellen Sie die Konsolencodepage mit chcp NNN (siehe unten):
3. Führen Sie powershell -noprof .

• Mit NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - keine Änderung der Schriftart
• Mit NNN = 65001, 858 und Nicht-WGL4 Hebräisch 862, Arabisch 864 - ändert sich die Schriftart.

Was zeichnet den CP 858 aus? Ich vermute, das könnte der Schlüssel sein. Der CP-Name lautet "OEM Multilingual Latin 1 + Euro Symbol".

Bemerkenswert ist auch, dass chcp 1255 und chcp 1266 (Hebräisch und Arabisch) die Schriftart auch in cmd.exe in "Courier New" ändern. PowerShell ist also möglicherweise nur irgendwie anfälliger, nicht der Hauptschuldige?

Obligatorische Versionsinfo:

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

Ich sollte auch erwähnen, obwohl dies höchstwahrscheinlich irrelevant ist: Ich habe ein hochauflösendes Display mit einer auf 150% eingestellten Anzeigeskala.

@ kkm000 Dies wurde in PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771) behoben, ist jedoch nicht in dem von Ihnen verwendeten Windows-Build enthalten, obwohl das Update in einem neueren Windows-Build eingecheckt wurde. Ich glaube, die neueste öffentliche Beta von PSReadLine hat das Update, so dass Sie es in Windows PowerShell installieren können, indem Sie:

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

Wenn sich beschwert, dass -AllowPrerelease nicht gefunden wird, müssen Sie PowerShellGet aktualisieren:

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

obwohl das Update in eine neuere Version von Windows eingecheckt wurde.

Bedeutet dies, dass das Update in einer zukünftigen (19H1) Insider-Version veröffentlicht wird?

@ 50Wliu ja

@ SteveL-MSFT Ich habe die gleiche Version wie @ kkm000 , ich habe dir Befehle ausgeführt und arbeite nicht für mich, ich vermisse etwas?

@ SteveL-MSFT Ich finde es sehr enttäuschend, dass dies nicht mit einem regulären Windows Update ausgeliefert werden kann. Wenn Microsoft mit einem Update etwas kaputt macht, liegt es in seiner Verantwortung, es mit einem Update zu reparieren und nicht um mehr als sechs Monate zu verschieben und zu planen, es mit der nächsten Windows-Version zu versenden, oder die Leute durch die Reifen springen zu lassen, um einen Hotfix von einem Pre- Update zu erhalten

Also ... ich musste diesen Befehl mehr als einmal ausführen

Installationsmodul Powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber

Wenn Powershell als Administrator ausgeführt wird, muss taskmgr Powershell beenden und dann erneut ausführen, da es zwei- oder dreimal fehlgeschlagen ist. Und… sieht so aus, als würde es funktionieren! Die benutzerdefinierten Anzeigeeinstellungen in meinem $ PROFILE verhalten sich jetzt wie vor dem Upgrade.

Dies hat gerade erst begonnen mit mir geschehen nach dem Upgrade auf die neuesten 1809 17763.292 Build aus dem vorherigen 1809 kumulativen Update. Ich habe die Anweisungen zur Installation der neuen PSReadLine befolgt und sie scheint dort zu sein:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
ich habe

PSVersion 5.1.17763.134

Die Consolas-Schriftart wird durch Raster-Schriftarten ersetzt.

AKTUALISIEREN

Dies scheint durch instabile Lösung. Jetzt nach dem Neustart hält / funktioniert der Fix, unabhängig von der Ausführungsstufe.

Interessantes Verhalten sehe ich jetzt. Nachdem ich das 'Fix' auf meinem Laptop ausgeführt habe
Name Wert
---- -----
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

Wenn Sie PS im Benutzermodus ausführen, ist die Korrektur in Ordnung. Wenn Sie PS als Administrator ausführen, funktioniert das Update nicht.

Funktioniert bei mir auch im Benutzermodus nicht.

@ SteveL-MSFT, sieht so aus, als ob das Update bei mir nicht funktioniert. Es scheint auch nicht, dass das Install-Modul etwas geändert hat. Ich habe bereits ein ziemlich aktuelles PowerShellGet ( -AllowPrerelease funktioniert auf jeden Fall; meine Schlüsselbindungen hängen von einer aktuellen PSReadLine ab). Ich habe PSReadLine vor einigen Monaten zum ersten Mal installiert (vor dem Upgrade von Windows!), Daher habe ich erwartet, dass ich heute ein Upgrade mit Ihrem vorgeschlagenen Befehl erhalten werde, aber ich habe keine Ahnung, wie ich bestätigen soll, ob tatsächlich etwas geändert wurde. Kannst du bitte helfen? Ich habe die Version von PSReadLine genommen, bevor ich das Upgrade versucht habe:

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

Dann habe ich ein Upgrade durchgeführt, wie Sie vorgeschlagen haben:

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

Das Install-Module wirbelte eine Weile herum, und oben auf dem Bildschirm war ein Fortschrittsbalken mit dem Stich 'o' zu sehen. Ich glaube nicht, dass dies etwas bedeutet, aber das Wiederholen des Installationsmoduls führt auch dazu, dass der Fortschrittsbalken für einen kurzen Moment angezeigt wird. Die neue Konsole leidet jedoch immer noch unter dem ursprünglichen Problem. Außerdem sehe ich hier keine Änderungen, vielleicht könnten Sie etwas erkennen? Ich kann mir sicherlich Dateiversionen usw. ansehen, die ich habe, ich weiß nur nicht, wonach ich suchen soll.

Dies hat auch nichts getan:

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

In der neuen Konsole scheint die neue (?) PSReadLine dieselbe zu sein:

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

Aufgrund der obigen Kommentare zu @ mjoyce6500 und habe ich außerdem die Benutzerkonsole (ohne Administratorrechte) überprüft und der Fehler wird wie zuvor

Bitte, ich freue mich über jede Hilfe / Gedanken, die Sie teilen könnten!

@ SteveL-MSFT, @lzybkr , ich glaube nicht, dass es ein Update in PSGallery gibt. Die neueste Beta wurde einen Monat vor dem Zusammenführen der Ausgabe lzybkr / PSReadLine # 771 veröffentlicht:

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

Leider enthält es keine ReleaseNotes mehr, wie es Beta2 getan hat. Aber das Timing schließt diese Möglichkeit sicherlich aus.

Anmerkung und Autor, Firma und Firma sind offenbar getauscht:

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

Author      : Microsoft Corporation
CompanyName : lzybkr

Das 'Fix' hat für mich immer noch gemischte Ergebnisse. Powershell im Benutzermodus funktioniert einwandfrei, keine Änderung an meinen benutzerdefinierten Farben / Schriftarten, nachdem der oben angegebene Befehl ausgeführt wurde. Obwohl Powershell im Admin-Modus nicht behoben wurde, wird das in diesem Fehler festgestellte Verhalten angezeigt.

@ mjoyce6500 Kannst du mir genaue Repro-Schritte geben? Beachten Sie auch, welchen Build von Windows und PSReadLine Sie verwenden. Vielen Dank.

@ SteveL-MSFT, kannst du dir bitte meinen Kommentar oben ansehen? Ich kann nicht einmal die aktualisierte Version von PSReadLine in PSGallery finden, während andere Leute berichten , „gemischte Ergebnisse.“ Derzeit ist die höchste verfügbare Version noch PSReadLine 2.0.0-beta3 18-09-04 21:59:13 , die einen Monat vor dem Zusammenführen des Fixes veröffentlicht wurde.

Wie finde ich heraus, welche Version ich verwende? Auf einem anderen Computer, auf dem ich Ihren Update-Vorschlag nie versucht habe, überprüfe ich die erste Zeile der Datei Changes.txt aus dem installierten Paket:

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

Dann versucht Install-Module tatsächlich, 2.0.0-beta3 zu installieren. Bestätigen Sie dies, indem Sie ohne -force ausführen:

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'.

Ist es möglich, dass ich das Update nicht von einem anderen Ort bekomme?

Nach dem Update hat die Changes.txt den Header 2.0.0-beta3 als erste Zeile:

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

Und die gleiche Reproduktion wie zuvor, Admin-Konsole oder nicht. Von der cmd.exe-Konsole mit Consolas-Schriftart:

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>

Natürlich erwarte ich nicht, dass es funktioniert, da ich die aktualisierte DLL nicht habe. Meine Frage ist, wie es möglich ist, dass andere Leute es haben.

Das gleiche Problem hier zu haben und das obige Update hatte keine Auswirkung.

Es ist immer noch umwerfend, wie das Update (zumindest teilweise) für die Minderheit der Menschen funktioniert hat, da es nie veröffentlicht wurde und hinter dieses Augenpaar schaut. Zu sagen, dass ich verblüfft bin, bedeutet nichts zu sagen. Meiner Meinung nach gibt es ZWEI PS-Galerien, und das Update wurde für eine von ihnen veröffentlicht, auf die nur wenige Personen zugreifen.

@ kkm000 Es gibt eine PSGallery und Beta.3 ist die neueste veröffentlichte PSReadLine. Die Version von PSReadLine 2.0.0, die in Win10 ausgeliefert wird, ist eine Abzweigung von PSReadLine 2.0.0 mit einigen neueren spezifischen Korrekturen, die in diesem Sinne der auf PSGallery veröffentlichten voraus sind.

@ SteveL-MSFT
Ich habe Beta3 installiert und nichts ist gelöst.
Beide mit Windows 1809 und 1903 (Build 18334.1)

@Borkason Das

Ich benutze Consolas. Es wird nach jedem Neustart der PowerShell zurückgeschaltet.

@Borkason welches Gebietsschema verwendest du? en-US oder etwas anderes?

de-DE

Es funktioniert jetzt plötzlich. Ich habe 10 Mal die Powershell geschlossen und geöffnet, aber jetzt scheint sie zu bleiben.

Es brach wieder. Anscheinend entscheidet es sich also zufällig, wieder zu brechen oder zu arbeiten. 💢

Ich hatte es mit 18334 geschehen - völlig zufällig. Ist nicht wieder passiert.

Okay, der Unterschied besteht darin, dass die Schriftart gleich bleibt, wenn ich Powershell über ALT-R starte. Wenn ich es über das Startmenü ausführe, wird die Schriftart auf Raster zurückgesetzt, auch wenn ich sie in der vorherigen Sitzung, die ich über das Startmenü ausgeführt habe, in Konsolen geändert habe.

(Und mit Startmenü meine ich eigentlich, dass ich die Windows-Taste auf der Tastatur drücke und dann 'Powershell' eingebe und die Eingabetaste drücke.)

@ SteveL-MSFT - Ich habe keine Version mit dem Font Fix für die PowerShell-Galerie veröffentlicht. Das Update ist jedoch im PSReadLine-Repo verfügbar, sodass Sie es selbst erstellen oder einen Build von AppVeyor herunterladen können.

@Borkason - Wenn Sie Consolas , sollten Sie den Schriftfehler nicht sehen.

Aufgrund der Abwärtskompatibilität bleibt es schwierig, Konsolenstandards festzulegen. Die Standardeinstellungen können in der Registrierung (pro Konsolenanwendung) oder in der Verknüpfung zum Starten der Konsolenanwendung festgelegt werden. Ich weiß, dass das Konsolenteam dieses Problem lösen möchte, aber es ist anscheinend ein schwieriges Problem.

Wenn Sie Consolas , sollten Sie den Schriftfehler nicht sehen.

Dann ist dieser Fehler nicht behoben, da ich Consolas verwende und die Verknüpfung auch.

Aufgrund der Abwärtskompatibilität bleibt es schwierig, Konsolenstandards festzulegen.

Dann sollte Microsoft ein Skript / FixIt-Tool für diejenigen bereitstellen, die nur möchten, dass ihre Konsole wieder funktioniert, unabhängig von der Abwärtskompatibilität ...

Ich weiß, dass das Konsolenteam dieses Problem lösen möchte, aber es ist anscheinend ein schwieriges Problem.

Offenbar. Und es ist offensichtlich auch unerträglich schwer, die verdammte PowerShell-Reparatur 1809 durchzuführen, ganz zu schweigen von 1903 ...

😠

Ich habe gerade auf 18342 aktualisiert und das Problem scheint behoben zu sein (18334 wird jedes Mal auf Raster-Schriftarten zurückgesetzt).

Ich bin immer noch damit einverstanden, dass das Update auf 1809 zurückportiert werden sollte.

BEARBEITEN: Problem mit der Fehlkonfiguration beim Upgrade (siehe https://github.com/Microsoft/console/issues/280#issuecomment-474917761). Der Fehler ist immer noch nicht behoben.

Ich habe gerade eine Neuinstallation von 20H1 durchgeführt. Problem ist immer noch da. 🤣 Das ist ein Witz, oder?

Dies kann durch Installieren der 1809 Windows 10 Rsat-Tools behoben werden.
Sie können RSAT nicht auf Computern installieren, auf denen die Home- oder Standard-Edition von Windows ausgeführt wird.
Sie können RSAT nur unter Windows 10 Professional oder Enterprise Edition installieren.

Methode 1 - Verwenden einer Funktion hinzufügen Installieren Sie die RSAT-Tools unter Windows 10, Version 1809

Klicken Sie zum Starten von RSAT Tools unter Windows 10 Version 1809 auf Start. Klicken Sie auf Einstellungen und auf der Einstellungsseite auf Apps.
Klicken Sie im rechten Bereich unter Apps und Funktionen auf Optionale Funktionen verwalten.
Klicken Sie nun auf + Feature hinzufügen. Warten Sie, bis die Liste der Features ausgefüllt ist.
Scrollen Sie nach unten, bis Sie RSAT-Funktionen sehen.
Wählen Sie nun eine der RSAT-Funktionen aus, die Sie installieren möchten. In diesem Fall wähle ich die Funktion RSAT: Gruppenrichtlinienverwaltungstools aus.
Klicken Sie auf Installieren.
Klicken Sie auf das Zurück-Symbol und warten Sie, bis die Funktion installiert ist.
Jetzt sollten Sie die Gruppenrichtlinienverwaltungstools unter Start> Windows-Verwaltung finden.

funktioniert vor Ort .... Installieren Sie RSAT Tools unter Windows 10 Version 1809 und höher
Von Prajwal Desai Zuletzt aktualisiert am 31. Januar 2019

Hoffe das hilft....

@RobRoberson du sagst , oder?

Ich habe das gleiche Problem unter Windows 1809 17763.316.
zh_Hans_CN mit aktivierter UTF-8-Option.

Werden Vorschauversionen das Problem lösen?

Werden Vorschauversionen das Problem lösen?

Nein.

Ich nehme zurück, was ich in https://github.com/Microsoft/console/issues/280#issuecomment -465837677 gesagt habe. Was tatsächlich geschah, war, dass alle meine Spracheinstellungen zurückgesetzt wurden, wodurch die 65001-Codepage ausgeschaltet wurde. Ich habe das heute gerade gemerkt, es wieder eingeschaltet und ... Hallo Raster-Schriften.

@ SteveL-MSFT Dieser Kommentar von Ihnen scheint falsch zu sein, da immer noch Leute sagen, dass dieses Problem ungelöst ist, selbst bei den neuesten Insider-Builds (ich bin zum Beispiel gerade auf 18361).

Würde gerne eine Lösung dafür finden. Wirklich wie Consolas für die Entwicklung unter Windows.

Durch die Verwendung der internen Microsoft 1903-Version kann bestätigt werden, dass dieser Fehler für Consolas und UFT8 weiterhin besteht. Die Schriftart von Lucida Console funktioniert jedoch und wird meine Problemumgehung sein

Wir arbeiten an einem neuen Update für PSReadLine, dann werden wir sehen, wie es in Windows integriert wird

Auf pwsh 6.2.0 schien dieses Problem behoben zu sein, aber es ist zurückgekommen, nachdem ich msbuild 2017 verwendet habe, um etwas zu erstellen (die Version 2015 war in Ordnung). Ich bin nicht sicher, wo genau dies geschieht, da es von node-gyp , aber wenn native Module (neu) erstellt werden müssen, wird meine Konsole wieder auf Raster-Schriftarten zurückgesetzt.

Zum Glück muss ich die Schriftarten nicht mehr jedes Mal zurücksetzen, wenn ich das Terminal öffne, sondern nur noch, wenn Node-Gyp ausgeführt wird.

PSReadLine 2.0.0-beta4 wurde veröffentlicht, das viele Probleme beheben sollte (obwohl es einige neue gibt). https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@ SteveL-MSFT 2.0.0-beta4 hat diesen Fehler nicht behoben.

Ich benutze ein normales CMD-Terminal mit gits bash.exe + phpunit = gleichem Problem. Es erscheint nach einigen Sekunden, in denen das Skript funktioniert.
Nicht sicher, der Grund in PowerShell ...

@ SteveL-MSFT 2.0.0-beta4 behebt den Fehler auch für mich nicht.

@sebgod Danke für den Tipp, ich habe von Consolas 16 zu Lucida Console 14 gewechselt, für meine Augen ist es ungefähr das Gleiche.

Ich werde jemanden das noch einmal untersuchen lassen

@ SteveL-MSFT Um dies zu replizieren, öffnen Sie eine Eingabeaufforderung und setzen Sie Ihre Schriftart auf Consolas.
und dann cmd /c chcp 65001 >NUL && powershell ausführen

Ok, ich glaube, ich habe das eigentliche Problem identifiziert und es hat nichts mit PSReadLine zu tun. In Windows PowerShell wird überprüft, ob die Codepage von der Consolas-Schriftart unterstützt wird. Die Liste ist hier . UTF-8 65001 ist nicht in dieser Liste enthalten. Wenn Windows PowerShell eine Codepage identifiziert, die von Consolas nicht unterstützt wird, wird die Schriftart in Terminal geändert. PowerShell Core 6.x verfügt nicht mehr über diesen Code, sodass Sie dieses Verhalten nicht sehen. Ich zögere, diesen Code zu ändern, da er möglicherweise etwas anderes beschädigt. Für meine eigenen Notizen steht dies in der Zeile 2648 von ConsoleControl.cs.

Ok, ich glaube, ich habe das eigentliche Problem identifiziert und es hat nichts mit PSReadLine zu tun. In Windows PowerShell wird überprüft, ob die Codepage von der Consolas-Schriftart unterstützt wird. Die Liste ist hier . UTF-8 65001 ist nicht in dieser Liste enthalten. Wenn Windows PowerShell eine Codepage identifiziert, die von Consolas nicht unterstützt wird, wird die Schriftart in Terminal geändert. PowerShell Core 6.x verfügt nicht mehr über diesen Code, sodass Sie dieses Verhalten nicht sehen. Ich zögere, diesen Code zu ändern, da er möglicherweise etwas anderes beschädigt. Für meine eigenen Notizen steht dies in der Zeile 2648 von ConsoleControl.cs.

Ich bin mir nicht sicher, wie dies etwas kaputt machen kann, da UTF-8 vor den neuesten Windows 10-Versionen nicht unterstützt wurde.

@sebgod break hier bedeutet etwas falsches Rendern, da Consolas sicher nicht alle von UTF-8 benötigten Glyphen hat

@ SteveL-MSFT Lucida Console, Courier New und alle anderen verfügbaren Schriftarten, die von diesem Problem nicht betroffen sind, obwohl sie auch die Codepage 65001 nicht unterstützen. Zufälligerweise unterstützt Consolas sogar mehr Codepages als Lucida Console. Warum passiert das nur bei Consolas?

Im Allgemeinen sollte es jedoch die Entscheidung des Benutzers sein, welche Schriftart für die Anzeige verwendet wird. Wenn keine Glyphen vorhanden sind, werden sie als � angezeigt und der Benutzer kann eine Entscheidung zum Ändern der Schriftart treffen.

@Borkason Ich denke, es ist aus Sicht eines englischen Muttersprachlers ein sehr klares Problem, aber es besteht kein Zweifel daran, dass internationale Benutzer Probleme haben, die wir nicht vorhersehen können.

Als beispielsweise @bitcrazed (ein anderes Mitglied des Microsoft Terminal-Teams) eine PR in cURL einführte, die die Windows VT-Unterstützung https://github.com/curl/curl/pull/3011 implementierte (wobei die Codepage geändert wurde) 65001) verursachte es ein Problem für internationale Benutzer: https://github.com/curl/curl/issues/3211

Dies erforderte einen Patch, der UTF-8 in die aktuelle Codepage schreibt und stattdessen APIs mit breiten Zeichenfolgen verwendet: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9

Es überrascht mich nicht, dass das Microsoft Terminal-Team danach sehr vorsichtig vorgehen möchte.

@sebgod break hier bedeutet etwas falsches Rendern, da Consolas sicher nicht alle von UTF-8 benötigten Glyphen hat

OK, es gibt keine einzige von Windows bereitgestellte Schriftart, die alle in UTF-8 definierten Glyphen abdeckt. Cmd.exe basiert auf einer Technologie namens Font Linking , um das Rendern aller Glyphen zu ermöglichen.
Bevor UTF-8 als Systemcodepage festgelegt wurde, musste man chcp 65001 manuell verwenden, aber es funktionierte ordnungsgemäß. Das Schriftverknüpfungsbit muss manuell in der Registrierung ausgeführt werden, damit es auf jeden Fall funktioniert.

@ImportTaste Ich glaube nicht, dass das etwas damit zu tun hat. Der Fallback wird nur wirksam, wenn Consolas verwendet wird. Wenn eine andere Schriftart wie Lucida Console oder Courier New verwendet wird, geschieht dies nicht. Zumindest hat Lucida Consolas die gleiche Codepage-Unterstützung wie Consolas, daher ist es schwer zu verstehen, warum dies so gemacht wurde. Wenn es ein Problem für internationale Benutzer geben würde (und ich bin übrigens kein englischer Muttersprachler, wie Sie annehmen), würde dies immer noch alle Benutzer betreffen, die Consolas nicht verwenden.

So wie ich es sehe, sollte der Fallback überhaupt nicht vorhanden sein (siehe PWSH 6 + 7) oder wurde schlampig implementiert (warum nur Consolas?).

@ SteveL-MSFT Und ich glaube, dass das Beheben überhaupt kein Risiko darstellt, da der Fehler nur mit Windows Version 1809 eingeführt wurde und es sich anscheinend um eine undokumentierte Änderung handelt, auch wenn niemand weiß, warum sie speziell geändert wurde.

@Borkason Wie gesagt, es war ein zuordenbares Beispiel für einen unerwarteten Fehler.

Ich bin überrascht zu hören, dass es angeblich nur eine Änderung von 1809 ist. Ich hatte in der Vergangenheit Probleme mit der Konsolenschriftart, die sich selbst in Raster geändert hat.

Es wurde erst 1809 erkannt, da die Standardschriftart für die Konsole Consolas war. Vorher glaube ich, dass es Lucida Console war? Und der Code funktionierte für diese Schriftart genauso. Mein Verständnis dieses Codes (der seit Ewigkeiten und vor meinem Team im PowerShell-Team vorhanden war) ist, dass in den Windows-Quellen nur eine Verknüpfung für PowerShell verwendet wird und diese Verknüpfung die Standardschriftart definiert. Als die Standardschriftart geändert wurde, beschwerten sich ostasiatische Benutzer, da ihre Glyphen nicht gerendert wurden, da die Schriftart dies nicht unterstützt. Dieser Code erkennt also, dass Schriftart und Gebietsschema nicht kompatibel sind, und wechselt zu einer, die gerendert wird.

Ich zögere, Änderungen an Windows PowerShell vorzunehmen, da selbst scheinbar kleine Änderungen wie diese zu unerwarteten Regressionen führen.

@sebgod & all: Ein paar Dinge hier:

Klarstellungen

1. Auf keiner Plattform gibt es eine einzelne Schriftart, die jede Glyphe für jeden Codepunkt enthält, der in UTF-8 dargestellt werden kann.
2. Cmd.exe weiß nichts über Schriftarten - Cmd.exe ist eine Shell
3. Die Konsole (ConHost.exe) bietet die traditionelle "terminalähnliche" Befehlszeilen-UX in Windows
4. Die aktuelle Text-Rendering-Engine der Konsole unterstützt kein Font-Fallback und kann die meisten Emoji nicht rendern. Probieren Sie es aus und Sie sehen das nicht anzeigbare Zeichen (Fragezeichen in einem Feld).

Terminal & Konsole

Windows Terminal ist unser neues Terminal UX der nächsten Generation. Es teilt mehrere gemeinsame Komponenten mit der In-Box-Konsole und fügt mehrere neue Funktionen hinzu, darunter einen Textpuffer und einen Textrenderer, in denen praktisch alle Unicode-Glyphen gespeichert und angezeigt werden können.

Diese Komponenten werden schließlich wieder in die In-Box-Konsole aufgenommen, jedoch erst, nachdem wir Terminal v1.0 veröffentlicht haben und Zeit hatten, sie in der Praxis zu testen.

Power Shell

Wie @ SteveL-MSFT hervorhebt, weist PowerShell Core (PSCore) dieses Problem nicht auf. Da PSCore die Zukunft von PowerShell ist, empfehlen wir Ihnen, es nach Möglichkeit zu verwenden.

Das Ändern des Verhaltens von PowerShell für Windows (PS) ist möglicherweise schwierig, da, wie wir aus dem Versuch wissen, das Verhalten von Cmd zu korrigieren / ändern, selbst kleine scheinbar harmlose Änderungen zu überraschenden Brüchen in der realen Welt führen können.

Ich werde dies mit Steve & Team besprechen und untersuchen, ob PS geändert werden kann, um eine Nicht-Raster-Schriftart (z. B. Consolas / Lucida / etc.) Für die Codepage 65001 auszuwählen.

@sebgod & all: Ein paar Dinge hier:

Klarstellungen

1. Auf keiner Plattform gibt es eine einzelne Schriftart, die jede Glyphe für jeden Codepunkt enthält, der in UTF-8 dargestellt werden kann.

Ja, deshalb habe ich gesagt: "Es gibt keine einzige von Windows bereitgestellte Schriftart, die alle in UTF-8 definierten Glyphen abdeckt."

1. Cmd.exe weiß nichts über Schriftarten - Cmd.exe ist eine Shell

Ja, entschuldigen Sie, dass Sie faul sind. Ich wollte nur darauf verweisen, was passiert, wenn Sie "cmd.exe" in das Windows-Suchfeld eingeben

1. Die Konsole (ConHost.exe) bietet die traditionelle "terminalähnliche" Befehlszeilen-UX in Windows
2. Die aktuelle Text-Rendering-Engine der Konsole unterstützt kein Font-Fallback und kann die meisten Emoji nicht rendern. Probieren Sie es aus und Sie sehen das nicht anzeigbare Zeichen (Fragezeichen in einem Feld).

Wie ich verstanden habe, kann die aktuelle Engine keine Zeichen aus höheren Unicode-Ebenen rendern, die (die meisten) Emoji-Zeichen enthalten.

Jetzt muss ich nicht wählerisch sein, ich habe über Font Linking gesprochen, das unterstützt wird oder zumindest funktioniert:

Durch Hinzufügen des Werts Lucida Console unter Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
mit Typ REG_MULTI_SZ und den folgenden Daten (oder ähnlichen, sollten monospaced Schriftarten sein):

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 ist möglich, die meisten Unicode-Glyphen der Grundebene anzuzeigen, wenn chcp 65001 oder seit 1803, indem die Systemcodepage auf UTF-8 gesetzt wird (Beta, funktioniert aber bisher). Ich persönlich bevorzuge es, die spezifischen Codepages für jede zu verwenden Sprache, da ich mehrere Sprachen benutze.

Jetzt bevorzuge ich Consolas, das seit 1903 nicht mehr funktioniert hat, weil es auf Raster-Schriftarten umgestellt hat.

Terminal & Konsole

Windows Terminal ist unser neues Terminal UX der nächsten Generation. Es teilt mehrere gemeinsame Komponenten mit der In-Box-Konsole und fügt mehrere neue Funktionen hinzu, darunter einen Textpuffer und einen Textrenderer, in denen praktisch alle Unicode-Glyphen gespeichert und angezeigt werden können.

Diese Komponenten werden schließlich wieder in die In-Box-Konsole aufgenommen, jedoch erst, nachdem wir Terminal v1.0 veröffentlicht haben und Zeit hatten, sie in der Praxis zu testen.

Ja, ich habe das neue Terminal UX bereits verwendet und es ist natürlich äußerst angenehm zu bedienen, aber es erlaubt derzeit keine Eingabe chinesischer Schriftzeichen (ich hoffe, dass dies irgendwann behoben wird).

Power Shell

Wie @ SteveL-MSFT hervorhebt, weist PowerShell Core (PSCore) dieses Problem nicht auf. Da PSCore die Zukunft von PowerShell ist, empfehlen wir Ihnen, es nach Möglichkeit zu verwenden.

Das Ändern des Verhaltens von PowerShell für Windows (PS) ist möglicherweise schwierig, da, wie wir aus dem Versuch wissen, das Verhalten von Cmd zu korrigieren / ändern, selbst kleine scheinbar harmlose Änderungen zu überraschenden Brüchen in der realen Welt führen können.

Ich werde dies mit Steve & Team besprechen und untersuchen, ob PS geändert werden kann, um eine Nicht-Raster-Schriftart (z. B. Consolas / Lucida / etc.) Für die Codepage 65001 auszuwählen.

Wenn Änderungen etwas kaputt machen können und wir sogar nicht genau wissen können, was, so dass im Terminal nie wieder etwas geändert werden kann?

Ich habe das Problem mit Powershell Core "behoben". Ich habe zuerst bemerkt, dass keine der Powershell-Einstellungen etwas bewirkt (aber die Einstellungen auf cmd.exe wurden geändert). Nachdem ich ein paar Stunden lang verschiedene Dinge ausprobiert hatte, stieß ich auf Powershell Core. Sobald ich es heruntergeladen hatte, wurden die zuvor gespeicherten Einstellungen wirksam, sobald ich die Vorschau auf Powershell Core öffnete.

Beim Ausführen einiger Befehle (einschließlich Scoop) vom FAR-Manager ist das gleiche Problem aufgetreten. Dieser Effekt ruiniert nur die Darstellung von FAR. Passiert nur mit aktivierter Consolas-Schriftart und Beta-Option, um die UTF-8-Codepage (65001) in der Konsole zu verwenden. Mein Gebietsschema ist russisch.

Als Endbenutzer - Es ist wirklich ärgerlich, wenn das Programm versucht, schlauer als ich zu sein. Ich kann mit Fragezeichen anstelle einiger UTF-8-Symbole leben, aber diese Schriftartänderung ruiniert nur die Anzeige von Programmen, die überhaupt nicht betroffen sein sollten, wie FAR Manager. Das ist ein Schmerz.

Im Moment musste ich für die Konsole auf das russische Gebietsschema zurückgreifen (zurück von UTF-8), dies schränkt jedoch die Arbeit mit Dateien ein, die mit Symbolen anderer Gebietsschemas benannt wurden. Ich hoffe, Sie können diese spezielle Consolas-Behandlung entfernen.

Ich habe das gleiche Problem, aber nur, wenn ich versuche, Konsolen zu verwenden. wahrscheinlich @ SteveL-MSFT ist richtig.
Ich habe Lucida Console ausprobiert und das funktioniert einwandfrei. Ich denke, Consolas fehlen einige Glyphen für utf-8 (meine Codepage)?!
Powershell Core 7 funktioniert gut mit allen Schriftarten.

Unglaublich, ich habe 2020 einen Windows-Laptop gekauft (xps15) und ich habe das gleiche Problem. Wahrscheinlich Hunderte von Windows-Updates später, und das Problem besteht weiterhin. Wenn PS Core 2019 die Zukunft war, warum wird es 2020 nicht installiert? Der PS Core könnte die Standardeinstellung sein, und möglicherweise könnte die alte PS als Ersatz installiert werden, falls jemand ein Kompatibilitätsproblem benötigt. Wie auch immer, ich habe das Windows-Terminal installiert und lass es uns versuchen.

@marcelomgarcia FWIW, der Grund, warum PowerShell 7 standardmäßig nicht in Windows installiert ist, liegt in Support- und Haftungsproblemen. Windows und PowerShell 7 haben unterschiedliche Unterstützung, und soweit ich das beurteilen kann, haben die Anwälte keinen Weg gefunden, dies zu tun. Vorerst jedenfalls. Ich bin sicher, dass jeder gerne PowerShell 7 in Windows 10 oder Windows Server sehen würde.

Denken Sie daran: Windows PowerShell ist eine Kernkomponente von Windows 10 und wird vom Standardinstallationsprogramm zu Ihrer auf Ihrem Laptop installierten Komponente hinzugefügt. Es ist eine vollständig unterstützte Komponente FWIW. Wenn Sie jedoch PowerShell 7 möchten, ist dies ein separater und nicht integrierter Installationsprozess.

Welche Sprache spricht Ihr Computer?

Danke für die Erklärung @doctordns. Es ist nur ein etwas frustrierendes Problem, und für jemanden außerhalb scheint es ein "einfaches" Problem zu sein. Ich installiere PowerShell 7.

Ich benutze Englisch US.