Windows 10 1809/19H1/20H1 breaks Powershell&#39;s console settings. Keeps opening with raster fonts. #414

@winstliu commented on GitHub (Oct 14, 2018):

The same happens to me only when using the Consolas font. If I use anything else - Courier New, Lucida Console, etc. - the settings are retained.

@winstliu commented on GitHub (Oct 14, 2018): The same happens to me only when using the Consolas font. If I use anything else - Courier New, Lucida Console, etc. - the settings are retained.

claunia commented

@danielniccoli commented on GitHub (Oct 15, 2018):

@50Wliu I can confirm that behaviour. Consolas resets to raster font. Lucida Console stays Lucida Console.

@danielniccoli commented on GitHub (Oct 15, 2018): @50Wliu I can confirm that behaviour. Consolas resets to raster font. Lucida Console stays Lucida Console.

claunia commented

@zadjii-msft commented on GitHub (Oct 15, 2018):

I'm almost certain this has to do with the fact that the new version of PSReadline is using the UTF8 codepage for displaying it's prompt, and when it does that, the console tries to recalculate the font.

I thought we had some issues tracking this previously, but I can't seem to find them. @bitcrazed do you remember where they were? Or was it an internal mail thread with @lzybkr and @SteveL-MSFT?

@zadjii-msft commented on GitHub (Oct 15, 2018): I'm almost certain this has to do with the fact that the new version of PSReadline is using the UTF8 codepage for displaying it's prompt, and when it does that, the console tries to recalculate the font. I thought we had some issues tracking this previously, but I can't seem to find them. @bitcrazed do you remember where they were? Or was it an internal mail thread with @lzybkr and @SteveL-MSFT?

claunia commented

@SteveL-MSFT commented on GitHub (Oct 15, 2018):

Can someone provide an exact repro? Like what font are you setting to the shortcut. What font is it being set to?

@SteveL-MSFT commented on GitHub (Oct 15, 2018): Can someone provide an exact repro? Like what font are you setting to the shortcut. What font is it being set to?

claunia commented

@danielniccoli commented on GitHub (Oct 15, 2018):

Win-R and run powershell.
It starts with raster font.
Go into settings and set the font to Consolas. Click OK.
Consolas is being applied.
Close Powershell.
Reopen powershell like before.
Font is raster font again.
Go into default settings and set the font to Consolas. Click OK.
Close Powershell.
Reopen powershell like before.
Font is raster font again.

@danielniccoli commented on GitHub (Oct 15, 2018): - `Win-R` and run `powershell`. - It starts with raster font. - Go into settings and set the font to Consolas. Click OK. - Consolas is being applied. - Close Powershell. - Reopen powershell like before. - Font is raster font again. - Go into default settings and set the font to Consolas. Click OK. - Close Powershell. - Reopen powershell like before. - Font is raster font again.

claunia commented

@miniksa commented on GitHub (Oct 15, 2018):

I don't think this was even Powershell's fault. I have a note sitting around here somewhere that one of the most recent .NET Frameworks (4.7something) suddenly decides to use 65001 as the default code page for all apps and when that flips back and forth with other tools and codepages as they start and exit, we recalculate the font.

I have a bug on me to try to make that less painful, but it's really the sudden flipping between codepages that is making this be a problem.

@miniksa commented on GitHub (Oct 15, 2018): I don't think this was even Powershell's fault. I have a note sitting around here somewhere that one of the most recent .NET Frameworks (4.7something) suddenly decides to use 65001 as the default code page for all apps and when that flips back and forth with other tools and codepages as they start and exit, we recalculate the font. I have a bug on me to try to make that less painful, but it's really the sudden flipping between codepages that is making this be a problem.

claunia commented

@doctordns commented on GitHub (Oct 17, 2018):

I can't reproduce this here. Both Windows PowerShell and Powershell both start up in the font I set.

@doctordns commented on GitHub (Oct 17, 2018): I can't reproduce this here. Both Windows PowerShell and Powershell both start up in the font I set.

claunia commented

@cloudhan commented on GitHub (Oct 17, 2018):

@Borkason Have you tried concfg clean
https://github.com/lukesampson/concfg

@cloudhan commented on GitHub (Oct 17, 2018): @Borkason Have you tried `concfg clean` https://github.com/lukesampson/concfg

claunia commented

@bitcrazed commented on GitHub (Oct 17, 2018):

@borakson - what locale is your Windows configured to use?

@bitcrazed commented on GitHub (Oct 17, 2018): @borakson - what locale is your Windows configured to use?

claunia commented

@winstliu commented on GitHub (Oct 17, 2018):

@bitcrazed I'm not @Borkason but since I'm experiencing this issue I'll answer as well.

My display language is Spanish (Spain), and so is my regional format. The language for programs that don't support Unicode is English (United States), and I have the beta checkbox selected for UTF-8 Unicode. (Hope that's what you're looking for...let me know if you were asking for something else)

@winstliu commented on GitHub (Oct 17, 2018): @bitcrazed I'm not @Borkason but since I'm experiencing this issue I'll answer as well. My display language is Spanish (Spain), and so is my regional format. The language for programs that don't support Unicode is English (United States), and I have the beta checkbox selected for UTF-8 Unicode. (Hope that's what you're looking for...let me know if you were asking for something else)

claunia commented

@danielniccoli commented on GitHub (Oct 19, 2018):

@bitcrazed German. And I upgraded from 1803. Forgot to meantion that.

@danielniccoli commented on GitHub (Oct 19, 2018): @bitcrazed German. And I upgraded from 1803. Forgot to meantion that.

claunia commented

@danielniccoli commented on GitHub (Oct 19, 2018):

@doctordns which font?

@danielniccoli commented on GitHub (Oct 19, 2018): @doctordns which font?

claunia commented

@doctordns commented on GitHub (Oct 19, 2018):

@doctordns which font?

I use Lucida Console (18 pt). But I've tested others and they too work after a restart of Windows PowerShell.

@doctordns commented on GitHub (Oct 19, 2018): > @doctordns which font? I use Lucida Console (18 pt). But I've tested others and they too work after a restart of Windows PowerShell.

claunia commented

@danielniccoli commented on GitHub (Oct 19, 2018):

The same happens to me only when using the Consolas font. If I use anything else - Courier New, Lucida Console, etc. - the settings are retained.

@danielniccoli commented on GitHub (Oct 19, 2018): > The same happens to me only when using the Consolas font. If I use anything else - Courier New, Lucida Console, etc. - the settings are retained.

claunia commented

@bitcrazed commented on GitHub (Nov 12, 2018):

This was likely fixed by @lzybkr's recent work: https://github.com/lzybkr/PSReadLine/issues/542

@Borkason & @doctordns - can you please confirm and close if fixed?

Thanks.

@bitcrazed commented on GitHub (Nov 12, 2018): This was likely fixed by @lzybkr's recent work: https://github.com/lzybkr/PSReadLine/issues/542 @Borkason & @doctordns - can you please confirm and close if fixed? Thanks.

claunia commented

@winstliu commented on GitHub (Nov 13, 2018):

@bitcrazed it looks like the issue you're referencing was fixed back in 2017 and as far as I can tell is included in the version of PSReadLine that 1809 ships with. Additionally, this issue is still occuring for me as of Windows Insiders build 18277.

@winstliu commented on GitHub (Nov 13, 2018): @bitcrazed it looks like the issue you're referencing was fixed back in 2017 and as far as I can tell is included in the version of PSReadLine that 1809 ships with. Additionally, this issue is still occuring for me as of Windows Insiders build 18277.

claunia commented

@danielniccoli commented on GitHub (Nov 15, 2018):

@bitcrazed That's one year older then the 1809 release. I wouldn't call that "recent".

And for me nothing changed. I'm on 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

But as @50Wliu already sayd, it's not even fixed in the current preview.

@danielniccoli commented on GitHub (Nov 15, 2018): @bitcrazed That's one year older then the 1809 release. I wouldn't call that "recent". And for me nothing changed. I'm on 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 ``` But as @50Wliu already sayd, it's not even fixed in the current preview.

claunia commented

@danielniccoli commented on GitHub (Nov 15, 2018):

Here is a link to the Feedback: https://aka.ms/AA37kk1

@danielniccoli commented on GitHub (Nov 15, 2018): Here is a link to the Feedback: https://aka.ms/AA37kk1

claunia commented

@lzybkr commented on GitHub (Nov 15, 2018):

@bitcrazed linked to the issue that caused the problem.

The fix is in this PR: https://github.com/lzybkr/PSReadLine/pull/771

@lzybkr commented on GitHub (Nov 15, 2018): @bitcrazed linked to the issue that caused the problem. The fix is in this PR: https://github.com/lzybkr/PSReadLine/pull/771

claunia commented

@danielniccoli commented on GitHub (Nov 15, 2018):

Fair enough. Is it known with what build the fix will ship?

@danielniccoli commented on GitHub (Nov 15, 2018): Fair enough. Is it known with what build the fix will ship?

claunia commented

@lzybkr commented on GitHub (Nov 15, 2018):

I'll try to release another beta to the PowerShell Gallery before the end of the year, but I don't know about Windows (I don't work on Windows).

@SteveL-MSFT owns the bits that ship in Windows, so maybe he can comment.

@lzybkr commented on GitHub (Nov 15, 2018): I'll try to release another beta to the PowerShell Gallery before the end of the year, but I don't know about Windows (I don't work on Windows). @SteveL-MSFT owns the bits that ship in Windows, so maybe he can comment.

claunia commented

@kid1412621 commented on GitHub (Nov 29, 2018):

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

same here...ready to re-install windows, REALLY painful!

@kid1412621 commented on GitHub (Nov 29, 2018): 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 same here...ready to re-install windows, REALLY painful!

claunia commented

@ghost commented on GitHub (Dec 13, 2018):

This problem seems links to fonts. I got the problem in Powershell with windows(cmd and Powershell core don't have this problem) when I set the font as 'Console', but when I change the font as 'Sarasa Mono SC', all work perfectly. I use 'Sarasa Mono SC' to show UTF-8 character, Windows 10 doesn't have a default font can show enough UTF-8 characters.

@ghost commented on GitHub (Dec 13, 2018): This problem seems links to fonts. I got the problem in Powershell with windows(cmd and Powershell core don't have this problem) when I set the font as 'Console', but when I change the font as 'Sarasa Mono SC', all work perfectly. I use 'Sarasa Mono SC' to show UTF-8 character, Windows 10 doesn't have a default font can show enough UTF-8 characters.

claunia commented

@xhxgit commented on GitHub (Dec 26, 2018):

Same here. Both my Surface & desktop PC.

@xhxgit commented on GitHub (Dec 26, 2018): Same here. Both my Surface & desktop PC.

claunia commented

@offero commented on GitHub (Jan 13, 2019):

Strangely I think I am experiencing this same issue but from a different way. Whenever a subprocess is opened to run powershell.exe, the console font changes to raster from Consolas.

Example 1: I have vim running (WSL) and it runs a powershell sub command to get the system clipboard. Every time I run that command, it resets the console font to raster fonts.

Example 2: I have a shell script that runs powershell as a subprocess to get the system nameservers. It causes the same thing to happen to the console, a switch to raster fonts. Nothing is output to the console. Everything happens in the subprocess.

The really strange part is that if I run powershell manually from the console (WSL), then it's fine and the font does not change.

@offero commented on GitHub (Jan 13, 2019): Strangely I think I am experiencing this same issue but from a different way. Whenever a subprocess is opened to run powershell.exe, the console font changes to raster from Consolas. Example 1: I have vim running (WSL) and it runs a powershell sub command to get the system clipboard. Every time I run that command, it resets the console font to raster fonts. Example 2: I have a shell script that runs powershell as a subprocess to get the system nameservers. It causes the same thing to happen to the console, a switch to raster fonts. Nothing is output to the console. Everything happens in the subprocess. The really strange part is that if I run powershell manually from the console (WSL), then it's fine and the font does not change.

claunia commented

@kkm000 commented on GitHub (Jan 13, 2019):

@bitcrazed, @SteveL-MSFT, @lzybkr: I have a good minimal repro. This started happening right after I upgraded the machine to Windows 1809. I had the font and console CP set before, as below, to Consolas and 65001 respectively, and everything worked just fine. I work with UTF-8 files, so the CP 65001 has been essential to me. My locale is plain old en-US, English language Windows 10 x64 Pro, and the OEM CP is the default 437.

Set the following registry keys (save as .reg and import). For some reason, it i important to change FontFamily, as the default may be different, and the font won't be applied.

Windows Registry Editor Version 5.00

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

Win+R cmd.exe ENTER. Console starts with the correct font and code page. Type chcp; it prints 65001 (if does not, run chcp 65001).
in the console, type powershell -noprof ('-noprof' to confirm that the issue is not related to anything I load in my profile).

As PowerShell starts, the console font immediately changes to a raster font, and the window resizes to accommodate. The raster font selected is Terminal, and does not even even have WGL4 characters (no Cyrillic or Greek). So this is certainly a bug.

The behavior reproduces even if running a non-interactive command, so it's rather doubtful that the bug is related to PSReadLine:

powershell -noprof -nonint -command "echo foo"

Also, the console font changes similarly (essentially, the console opens in a raster font) if PowerShell is ran via a shortcut, or from the Win+R dialog, or by double-clicking in Explorer.

Also, some negatives. The font is not changed if either:

I run chcp 437 before invoking powershell from cmd.
The console font is set in the registry to "Lucida Console" (everything else stays same as above). That this font is somehow "special" has been already noted in the comments in this ticket.

The common theme in the comments in this issue has been, I believe, a non-US, European locale (German ans Spanish were mentioned). So i tried the following:

Start cmd.exe
Set console code page with chcp NNN (see below):
Run powershell -noprof.

With NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - no font change
With NNN = 65001, 858, and non-WGL4 Hebrew 862, Arabic 864 - font does change.

What sets the CP 858 apart? My guess is this may be the key. The CP name is "OEM Multilingual Latin 1 + Euro symbol".

Also notable is that chcp 1255 and chcp 1266 (Hebrew and Arabic) change font to "Courier New" even in cmd.exe. So PowerShell may be only somehow more susceptible, not the main culprit?

Obligatory version info:

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

Also, I should mention, although this is most likely irrelevant: I have a high-DPI display with the display scale set to 150%.

@kkm000 commented on GitHub (Jan 13, 2019): @bitcrazed, @SteveL-MSFT, @lzybkr: I have a good minimal repro. This started happening right after I upgraded the machine to Windows 1809. I had the font and console CP set before, as below, to Consolas and 65001 respectively, and everything worked just fine. I work with UTF-8 files, so the CP 65001 has been essential to me. My locale is plain old en-US, English language Windows 10 x64 Pro, and the OEM CP is the default 437. 1. Set the following registry keys (save as .reg and import). For some reason, it i important to change FontFamily, as the default may be different, and the font won't be applied. ``` Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console] "FaceName"="Consolas" "FontFamily"=dword:00000036 "FontSize"=dword:000f0000 "FontWeight"=dword:00000190 "CodePage"=dword:0000fde9 ``` 2. <kbd>Win+R</kbd> `cmd.exe` <kbd>ENTER</kbd>. Console starts with the correct font and code page. Type `chcp`; it prints 65001 (if does not, run `chcp 65001`). 3. in the console, type `powershell -noprof` ('-noprof' to confirm that the issue is not related to anything I load in my profile). As PowerShell starts, the console font immediately changes to a raster font, and the window resizes to accommodate. The raster font selected is Terminal, and does not even even have WGL4 characters (no Cyrillic or Greek). So this is certainly a bug. The behavior reproduces even if running a non-interactive command, so it's rather doubtful that the bug is related to PSReadLine: ``` powershell -noprof -nonint -command "echo foo" ``` Also, the console font changes similarly (essentially, the console opens in a raster font) if PowerShell is ran via a shortcut, or from the Win+R dialog, or by double-clicking in Explorer. Also, some negatives. The font is **not** changed if either: * I run `chcp 437` before invoking `powershell` from cmd. * The console font is set in the registry to "Lucida Console" (everything else stays same as above). That this font is somehow "special" has been already noted in the comments in this ticket. The common theme in the comments in this issue has been, I believe, a non-US, European locale (German ans Spanish were mentioned). So i tried the following: 1. Start cmd.exe 2. Set console code page with `chcp NNN` (see below): 3. Run `powershell -noprof`. * With NNN = 437, 1252, 1251, 1253, 850, 852, 869, 857, 737 - no font change * With NNN = 65001, 858, and non-WGL4 Hebrew 862, Arabic 864 - font does change. What sets the CP 858 apart? My guess is this may be the key. The CP name is "OEM Multilingual Latin 1 + Euro symbol". Also notable is that `chcp 1255` and `chcp 1266` (Hebrew and Arabic) change font to "Courier New" **even in cmd.exe**. So PowerShell may be only somehow more susceptible, not the main culprit? Obligatory version info: ``` 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 ``` Also, I should mention, although this is most likely irrelevant: I have a high-DPI display with the display scale set to 150%.

claunia commented

@SteveL-MSFT commented on GitHub (Jan 15, 2019):

@kkm000 This was fixed in PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771), but isn't in the build of Windows you are using, although the fix was checked into a newer build of Windows. I believe the newest public Beta of PSReadLine has the fix, so you can install it in Windows PowerShell using:

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

If it complains that -AllowPrerelease isn't found, you'll have to update PowerShellGet:

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

@SteveL-MSFT commented on GitHub (Jan 15, 2019): @kkm000 This was fixed in PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771), but isn't in the build of Windows you are using, although the fix was checked into a newer build of Windows. I believe the newest public Beta of PSReadLine has the fix, so you can install it in Windows PowerShell using: ```powershell install-module psreadline -AllowPrerelease -Repository PSGallery -Force # restart PowerShell to load the new one ``` If it complains that `-AllowPrerelease` isn't found, you'll have to update PowerShellGet: ```powershell install-module powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber # restart PowerShell to load the new one ```

claunia commented

@winstliu commented on GitHub (Jan 15, 2019):

although the fix was checked into a newer build of Windows.

Does this mean that the fix will be coming to a future (19H1) Insiders release?

@winstliu commented on GitHub (Jan 15, 2019): > although the fix was checked into a newer build of Windows. Does this mean that the fix will be coming to a future (19H1) Insiders release?

claunia commented

@SteveL-MSFT commented on GitHub (Jan 15, 2019):

@50Wliu yes

@SteveL-MSFT commented on GitHub (Jan 15, 2019): @50Wliu yes

claunia commented

@sl1pkn07 commented on GitHub (Jan 16, 2019):

@SteveL-MSFT i have the same version like @kkm000 , i ran you commands and not work for me, i miss something?

@sl1pkn07 commented on GitHub (Jan 16, 2019): @SteveL-MSFT i have the same version like @kkm000 , i ran you commands and not work for me, i miss something?

claunia commented

@danielniccoli commented on GitHub (Jan 18, 2019):

@SteveL-MSFT I find it very disappointing that this cannot be shipped with a regular Windows Update. If Microsoft breaks something with an update, it's their responsibility to fix it with an update and not postpone it for over six months and plan to ship it with the next Windows version, or have people jump through hoops to get a hotfix from a pre-release repository (which doesn't even work for everyone).

@danielniccoli commented on GitHub (Jan 18, 2019): @SteveL-MSFT I find it very disappointing that this cannot be shipped with a regular Windows Update. If Microsoft breaks something with an update, it's their responsibility to fix it with an update and not postpone it for over six months and plan to ship it with the next Windows version, or have people jump through hoops to get a hotfix from a *pre-release* repository (which doesn't even work for everyone).

claunia commented

@mjoyce6500 commented on GitHub (Jan 25, 2019):

so.... I had to run that command more than once

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

with powershell running as admin, taskmgr to kill powershell and then do it again since it failed two or three times. And … looks like its working! The customized display settings in my $PROFILE are now behaving as they were before the upgrade.

@mjoyce6500 commented on GitHub (Jan 25, 2019): so.... I had to run that command more than once install-module powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber with powershell running as admin, taskmgr to kill powershell and then do it again since it failed two or three times. And … looks like its working! The customized display settings in my $PROFILE are now behaving as they were before the upgrade.

claunia commented

@wigster commented on GitHub (Jan 29, 2019):

This has just started to happen to me after the upgrade to the latest 1809 17763.292 build from the previous 1809 cumulative update. I followed the instructions to install the new PSReadLine and it seems to be there:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
I have

PSVersion 5.1.17763.134

Consolas font gets replaced with raster fonts.

@wigster commented on GitHub (Jan 29, 2019): This has just *started* to happen to me after the upgrade to the latest 1809 17763.292 build from the previous *1809* cumulative update. I followed the instructions to install the new PSReadLine and it seems to be there: `Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov` I have `PSVersion 5.1.17763.134` Consolas font gets replaced with raster fonts.

claunia commented

@mjoyce6500 commented on GitHub (Jan 30, 2019):

UPDATE

this seems to by unstable fix. Now after reboot the fix is holding/working, regardless of run level.

Interesting behavior I am now seeing. After running the 'fix' on my laptop
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

when running PS in user mode, fix is fine; when running PS as admin, fix does not work.

@mjoyce6500 commented on GitHub (Jan 30, 2019): *UPDATE* this seems to by unstable fix. Now after reboot the fix is holding/working, regardless of run level. ---------------------------------------------------------------------------------------- Interesting behavior I am now seeing. After running the 'fix' on my laptop 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 when running PS in user mode, fix is fine; when running PS as admin, fix does not work.

claunia commented

@wigster commented on GitHub (Jan 30, 2019):

Doesn't work for me even in user mode.

@wigster commented on GitHub (Jan 30, 2019): Doesn't work for me even in user mode.

claunia commented

@kkm000 commented on GitHub (Feb 2, 2019):

@SteveL-MSFT, looks like the fix does not work for me. Also, it does not seem that the Install-Module has changed anything. I already have a pretty latest PowerShellGet (-AllowPrerelease certainly works; my key bindings depend on a recent PSReadLine). I've initially installed PSReadLine a few months ago (before upgrading Windows!), so I expected that I will get an upgrade today with your suggested command, but I have no idea how to confirm if anything has been in fact changed. Could you please help? I took the version of PSReadLine before attempting the upgrade:

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

Then I upgraded, as you suggested:

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

The Install-Module churned for a while, and a progress bar with the sting of 'o's streaked at the top of the screen. I do not believe this means anything, but repeating the Install-Module also causes the progress bar to appear for a brief moment. But the new console still suffers from the original problem. Also, I do not see any changes here, maybe you could spot something? I can certainly look at file versions etc. that I have, I only do not know what to look for.

This did not do anything either:

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

In the new console, the new(?) PSReadLine seems same:

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

Also, due to @mjoyce6500 and @wigster comments above, I checked the user (non-admin) console, and it also shows the bug as it did before.

Please, I'll appreciate any help/thoughts you might share!

@kkm000 commented on GitHub (Feb 2, 2019): @SteveL-MSFT, looks like the fix does not work for me. Also, it does not seem that the Install-Module has changed anything. I already have a pretty latest PowerShellGet (`-AllowPrerelease` certainly works; my key bindings depend on a recent PSReadLine). I've initially installed PSReadLine a few months ago (before upgrading Windows!), so I expected that I will get an upgrade today with your suggested command, but I have no idea how to confirm if anything has been in fact changed. Could you please help? I took the version of PSReadLine before attempting the upgrade: ``` 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 : {} ``` Then I upgraded, as you suggested: ``` C:\WINDOWS\system32> install-module psreadline -AllowPrerelease -Repository PSGallery -Force C:\WINDOWS\system32> exit ``` The `Install-Module` churned for a while, and a progress bar with the sting of 'o's streaked at the top of the screen. I do not believe this means anything, but repeating the Install-Module also causes the progress bar to appear for a brief moment. But the new console still suffers from the original problem. Also, I do not see any changes here, maybe you could spot something? I can certainly look at file versions etc. that I have, I only do not know what to look for. This did not do anything either: ``` C:\WINDOWS\system32> Update-Module PSReadLine -AllowPrerelease C:\WINDOWS\system32> ``` In the new console, the new(?) PSReadLine seems same: ``` 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 : {} ``` Also, due to @mjoyce6500 and @wigster comments above, I checked the user (non-admin) console, and it also shows the bug as it did before. Please, I'll appreciate any help/thoughts you might share!

claunia commented

@kkm000 commented on GitHub (Feb 2, 2019):

@SteveL-MSFT, @lzybkr, I do not think there is an update in PSGallery. The latest beta had been published a month before the issue lzybkr/PSReadLine#771 was merged:

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

Unfortunately, it does not include ReleaseNotes any more, like beta2 did. But timing certainly excludes this possibility.

Unrelated note, Author and Company are apparently swapped:

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

Author      : Microsoft Corporation
CompanyName : lzybkr

@kkm000 commented on GitHub (Feb 2, 2019): @SteveL-MSFT, @lzybkr, I do not think there is an update in PSGallery. The latest beta had been published a month before the issue lzybkr/PSReadLine#771 was merged: ``` 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 ``` Unfortunately, it does not include ReleaseNotes any more, like beta2 did. But timing certainly excludes this possibility. Unrelated note, Author and Company are apparently swapped: ``` C:\WINDOWS\system32> Find-Module PSReadline -req 2.0.0-beta3 -Repository PSGallery -AllowPrerelease | fl author,compan* Author : Microsoft Corporation CompanyName : lzybkr ```

claunia commented

@mjoyce6500 commented on GitHub (Feb 8, 2019):

The 'fix' still has mixed results for me. Powershell in user mode is working fine, no change to my custom colors/fonts after running the command noted above. Though Powershell in Admin mode not fixed, shows the behavior noted in this bug.

@mjoyce6500 commented on GitHub (Feb 8, 2019): The 'fix' still has mixed results for me. Powershell in user mode is working fine, no change to my custom colors/fonts after running the command noted above. Though Powershell in Admin mode not fixed, shows the behavior noted in this bug.

claunia commented

@SteveL-MSFT commented on GitHub (Feb 8, 2019):

@mjoyce6500 can you give me exact repro steps? Also note what build of Windows and PSReadLine you are using. Thanks.

@SteveL-MSFT commented on GitHub (Feb 8, 2019): @mjoyce6500 can you give me exact repro steps? Also note what build of Windows and PSReadLine you are using. Thanks.

claunia commented

@kkm000 commented on GitHub (Feb 10, 2019):

@SteveL-MSFT, could you please have a look at my comment above? I cannot even find the updated version of PSReadLine in PSGallery, while other people report "mixed results." As of right now, the highest available version is still PSReadLine 2.0.0-beta3 18-09-04 21:59:13, published a month before the fix was merged.

Also, how do I find out the version that I am using? On another machine, where I never attempted your update suggestion, checking the first line of the file Changes.txt from the installed package:

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

Then, Install-Module indeed attempts to install 2.0.0-beta3, confirm by running without -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'.

Is it possible that I am getting the update not from somewhere other people do?

After the update, the Changes.txt has 2.0.0-beta3 header as the first line:

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

And the same reproduction as before, admin console or not. From cmd.exe console with Consolas font:

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>

Of course, I do not expect it to work, as I do not have the updated DLL. My question is, how it is possible that other people may have it.

@kkm000 commented on GitHub (Feb 10, 2019): @SteveL-MSFT, could you please have a look at my [comment above](https://github.com/Microsoft/console/issues/280#issuecomment-460003585)? I cannot even *find* the updated version of PSReadLine in PSGallery, while other people report "mixed results." As of right now, the highest available version is still `PSReadLine 2.0.0-beta3 18-09-04 21:59:13`, published a month before the fix was merged. Also, how do I find out the version that I am using? On another machine, where I never attempted your update suggestion, checking the first line of the file Changes.txt from the installed package: ``` 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 ``` Then, Install-Module indeed attempts to install 2.0.0-beta3, confirm by running without `-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'. ``` Is it possible that I am getting the update not from somewhere other people do? After the update, the Changes.txt has 2.0.0-beta3 header as the first line: ``` C:\WINDOWS\system32> gc "C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\Changes.txt" | select -first 1 ### Version 2.0.0-beta3 ``` And the same reproduction as before, admin console or not. From cmd.exe console with Consolas font: ``` 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> ``` Of course, I do not expect it to work, as I do not have the updated DLL. My question is, how it is possible that other people may have it.

claunia commented

@mdsharpe commented on GitHub (Feb 15, 2019):

Having the same problem here, and the above fix has had no effect.

@mdsharpe commented on GitHub (Feb 15, 2019): Having the same problem here, and the above fix has had no effect.

claunia commented

@kkm000 commented on GitHub (Feb 15, 2019):

It is still mindboggling how the fix worked (at least partially) for the minority of people, given that it was never released, looking from behind this pair of eyes. To say I am baffled is to say nothing. My current thinking is there are TWO PS galleries, and the fix has been published to the one of them which only a few people are accessing.

@kkm000 commented on GitHub (Feb 15, 2019): It is still mindboggling how the fix worked (at least partially) for the minority of people, given that it was never released, looking from behind this pair of eyes. To say I am baffled is to say nothing. My current thinking is there are TWO PS galleries, and the fix has been published to the one of them which only a few people are accessing.

claunia commented

@SteveL-MSFT commented on GitHub (Feb 20, 2019):

@kkm000 There is one PSGallery and beta.3 is the latest PSReadLine published. The version of PSReadLine 2.0.0 that ships in Win10 is a fork of PSReadLine 2.0.0 with some newer specific fixes taken so in that sense it is ahead of the one published on PSGallery.

@SteveL-MSFT commented on GitHub (Feb 20, 2019): @kkm000 There is one PSGallery and beta.3 is the latest PSReadLine published. The version of PSReadLine 2.0.0 that ships in Win10 is a fork of PSReadLine 2.0.0 with some newer specific fixes taken so in that sense it is ahead of the one published on PSGallery.

claunia commented

@danielniccoli commented on GitHub (Feb 20, 2019):

@SteveL-MSFT
I installed beta3 and nothing is resolved.
Both with Windows 1809 and 1903 (Build 18334.1)

@danielniccoli commented on GitHub (Feb 20, 2019): @SteveL-MSFT I installed beta3 and **nothing** is resolved. Both with Windows 1809 and 1903 (Build 18334.1)

claunia commented

@SteveL-MSFT commented on GitHub (Feb 20, 2019):

@Borkason the fix for not changing the font if not using a raster font should already be in that build. What font are you using?

@SteveL-MSFT commented on GitHub (Feb 20, 2019): @Borkason the fix for not changing the font if not using a raster font should already be in that build. What font are you using?

claunia commented

@danielniccoli commented on GitHub (Feb 20, 2019):

I'm using Consolas. It switches back after every restart of the PowerShell.

@danielniccoli commented on GitHub (Feb 20, 2019): I'm using Consolas. It switches back after every restart of the PowerShell.

claunia commented

@SteveL-MSFT commented on GitHub (Feb 20, 2019):

@Borkason what locale are you using? en-US or something else?

@SteveL-MSFT commented on GitHub (Feb 20, 2019): @Borkason what locale are you using? en-US or something else?

claunia commented

@danielniccoli commented on GitHub (Feb 20, 2019):

de-DE

It's suddenly working now. Took me like 10 times closing and opening the powershell, but now it seems to stick.

@danielniccoli commented on GitHub (Feb 20, 2019): de-DE It's suddenly working now. Took me like 10 times closing and opening the powershell, but now it seems to stick.

claunia commented

@danielniccoli commented on GitHub (Feb 20, 2019):

It broke again. So apparently it randomly decides to break again, or work. 💢

@danielniccoli commented on GitHub (Feb 20, 2019): It broke again. So apparently it randomly decides to break again, or work. 💢

claunia commented

@oising commented on GitHub (Feb 20, 2019):

I had it happen with 18334 -- completely randomly. Didn't happen again.

@oising commented on GitHub (Feb 20, 2019): I had it happen with 18334 -- completely randomly. Didn't happen again.

claunia commented

@danielniccoli commented on GitHub (Feb 20, 2019):

Okay, so the difference is that when I run powershell via ALT-R, then the font stays the same. When I run it from the start menu, then it resets the font to raster, even when I changed it to consolas in the previous session that I ran from the start menu.

(And by start menu I actually mean that I press the Windows key on the keyboard and then type 'powershell' and press enter.)

@danielniccoli commented on GitHub (Feb 20, 2019): Okay, so the difference is that when I run powershell via ALT-R, then the font stays the same. When I run it from the start menu, then it resets the font to raster, even when I changed it to consolas in the previous session that I ran from the start menu. (And by start menu I actually mean that I press the Windows key on the keyboard and then type 'powershell' and press enter.)

claunia commented

@lzybkr commented on GitHub (Feb 20, 2019):

@SteveL-MSFT - I have not published a release with the font fix to the PowerShell gallery. The fix is available in the PSReadLine repo though, so you can build it yourself or grab a build from AppVeyor.

@Borkason - If you're using Consolas then I think you shouldn't be seeing the font bug.

It remains difficult to set console defaults because of backwards compatibility. Defaults can be set in the registry (per console application) or in the shortcut used to start the console application. I know the console team wants to solve that problem, but it is apparently a hard problem.

@lzybkr commented on GitHub (Feb 20, 2019): @SteveL-MSFT - I have not published a release with the font fix to the PowerShell gallery. The fix is available in the PSReadLine repo though, so you can build it yourself or grab a build from AppVeyor. @Borkason - If you're using `Consolas` then I think you shouldn't be seeing the font bug. It remains difficult to set console defaults because of backwards compatibility. Defaults can be set in the registry (per console application) or in the shortcut used to start the console application. I know the console team wants to solve that problem, but it is apparently a hard problem.

claunia commented

@danielniccoli commented on GitHub (Feb 20, 2019):

If you're using Consolas then I think you shouldn't be seeing the font bug.

Then this bug is not resolved, because I am using Consolas and the shortcut does, too.

It remains difficult to set console defaults because of backwards compatibility.

Then Microsoft should provide a script/FixIt-tool for those who just want their console to work again, regardless of backwards compatibility ...

I know the console team wants to solve that problem, but it is apparently a hard problem.

Apparently. And it's obvisouly also excruciatingly hard to put the damn PowerShell half-fix into 1809, not to mention 1903 ...

😠

@danielniccoli commented on GitHub (Feb 20, 2019): > If you're using `Consolas` then I think you shouldn't be seeing the font bug. Then this bug is not resolved, because I am using Consolas and the shortcut does, too. ![grafik](https://user-images.githubusercontent.com/2971735/53122232-65081980-3556-11e9-82ec-687f0c0a5d8e.png) ![grafik](https://user-images.githubusercontent.com/2971735/53122276-7d783400-3556-11e9-82c2-c949bb72e882.png) > It remains difficult to set console defaults because of backwards compatibility. Then Microsoft should provide a script/FixIt-tool for those who just want their console to work again, regardless of backwards compatibility ... > I know the console team wants to solve that problem, but it is apparently a hard problem. Apparently. And it's obvisouly also excruciatingly hard to put the damn PowerShell half-fix into 1809, not to mention 1903 ... 😠

claunia commented

@winstliu commented on GitHub (Feb 21, 2019):

~~I just updated to 18342 and the issue seems to be fixed (18334 still reset to raster fonts each time).~~

~~I still agree that the fix should be backported to 1809.~~

EDIT: Misconfiguration issue on upgrade (see https://github.com/Microsoft/console/issues/280#issuecomment-474917761). The bug still isn't fixed.

@winstliu commented on GitHub (Feb 21, 2019): ~~I just updated to 18342 and the issue seems to be fixed (18334 still reset to raster fonts each time).~~ ~~I still agree that the fix should be backported to 1809.~~ EDIT: Misconfiguration issue on upgrade (see https://github.com/Microsoft/console/issues/280#issuecomment-474917761). The bug still isn't fixed.

claunia commented

@danielniccoli commented on GitHub (Mar 2, 2019):

I just did a fresh install of 20H1. Problem is still there. 🤣 This is a joke, right?

@danielniccoli commented on GitHub (Mar 2, 2019): I just did a fresh install of 20H1. Problem is still there. 🤣 This is a joke, right?

claunia commented

@RobRoberson commented on GitHub (Mar 11, 2019):

This can be fixed by installing the 1809 windows 10 Rsat tools.
You cannot install RSAT on computers that are running Home or Standard editions of Windows.
You can install RSAT only on Windows 10 Professional or Enterprise editions.

Method 1 – Using Add a Feature Install RSAT Tools on Windows 10 version 1809

To install RSAT Tools on Windows 10 version 1809, click Start. Click Settings and from the settings page, click Apps.
On the right pane, under Apps & features, click Manage optional features.
Now click + Add a feature.Wait for the list of features to be populated.
Scroll down until you see RSAT features.
Now select any of the RSAT feature that you wish to install. In this case, I am selecting RSAT: Group Policy Management Tools feature.
Click Install.
Click the back icon and wait until the feature is installed.
Now you should find Group Policy Management Tools under Start > Windows Administrative Tools.

works sited.... Install RSAT Tools on Windows 10 version 1809 and later
By Prajwal Desai Last updated Jan 31, 2019

Hope this helps....

@RobRoberson commented on GitHub (Mar 11, 2019): This can be fixed by installing the 1809 windows 10 Rsat tools. You cannot install RSAT on computers that are running Home or Standard editions of Windows. You can install RSAT only on Windows 10 Professional or Enterprise editions. Method 1 – Using Add a Feature Install RSAT Tools on Windows 10 version 1809 To install RSAT Tools on Windows 10 version 1809, click Start. Click Settings and from the settings page, click Apps. On the right pane, under Apps & features, click Manage optional features. Now click + Add a feature.Wait for the list of features to be populated. Scroll down until you see RSAT features. Now select any of the RSAT feature that you wish to install. In this case, I am selecting RSAT: Group Policy Management Tools feature. Click Install. Click the back icon and wait until the feature is installed. Now you should find Group Policy Management Tools under Start > Windows Administrative Tools. works sited.... Install RSAT Tools on Windows 10 version 1809 and later By Prajwal Desai Last updated Jan 31, 2019 Hope this helps....

claunia commented

@yw662 commented on GitHub (Mar 11, 2019):

@RobRoberson you really understand what you are saying, right?

I have the same issue on windows 1809 17763.316.
zh_Hans_CN with the UTF-8 option enabled.

Will preview versions solve the problem ?

@yw662 commented on GitHub (Mar 11, 2019): @RobRoberson you really understand what you are saying, right? I have the same issue on windows 1809 17763.316. zh_Hans_CN with the UTF-8 option enabled. Will preview versions solve the problem ?

claunia commented

@danielniccoli commented on GitHub (Mar 11, 2019):

Will preview versions solve the problem ?

No.

@danielniccoli commented on GitHub (Mar 11, 2019): > Will preview versions solve the problem ? No.

claunia commented

@winstliu commented on GitHub (Mar 20, 2019):

I take back what I said in https://github.com/Microsoft/console/issues/280#issuecomment-465837677. What actually happened was that all my language settings got reset, which turned off the 65001 codepage. I just realized that today, switched it back on, and...hello raster fonts.

@SteveL-MSFT this comment of yours seems incorrect by the amount of people still saying that this issue is unresolved, even on the latest Insider builds (I'm on 18361 right now, for example).

@winstliu commented on GitHub (Mar 20, 2019): I take back what I said in https://github.com/Microsoft/console/issues/280#issuecomment-465837677. What actually happened was that all my language settings got reset, which turned off the 65001 codepage. I just realized that today, switched it back on, and...hello raster fonts. @SteveL-MSFT [this comment](https://github.com/Microsoft/console/issues/280#issuecomment-465729345) of yours seems incorrect by the amount of people still saying that this issue is unresolved, even on the latest Insider builds (I'm on 18361 right now, for example).

claunia commented

@wbeeftink commented on GitHub (Apr 16, 2019):

Would love a fix on this. Really like Consolas for development under Windows.

@wbeeftink commented on GitHub (Apr 16, 2019): Would love a fix on this. Really like Consolas for development under Windows.

claunia commented

@sebgod commented on GitHub (Apr 20, 2019):

Using the internal Microsoft 1903 release can confirm this bug still exists for Consolas and UFT8. Lucida Console font works though and will be my workaround

@sebgod commented on GitHub (Apr 20, 2019): Using the internal Microsoft 1903 release can confirm this bug still exists for Consolas and UFT8. Lucida Console font works though and will be my workaround

claunia commented

@SteveL-MSFT commented on GitHub (Apr 24, 2019):

We're working on a new update to PSReadLine, then we'll see about getting it into Windows

@SteveL-MSFT commented on GitHub (Apr 24, 2019): We're working on a new update to PSReadLine, then we'll see about getting it into Windows

claunia commented

@winstliu commented on GitHub (May 20, 2019):

On pwsh 6.2.0, this issue seemed to have been resolved, but it's come back after I use msbuild 2017 to build anything (the 2015 version was fine). I'm not sure where exactly this is happening because it's from node-gyp, but if native modules need to be (re)built, my console will revert back to raster fonts.

Thankfully, I no longer have to reset the fonts every single time I open the terminal, only when running node-gyp.

@winstliu commented on GitHub (May 20, 2019): On pwsh 6.2.0, this issue seemed to have been resolved, but it's come back after I use msbuild 2017 to build anything (the 2015 version was fine). I'm not sure where exactly this is happening because it's from `node-gyp`, but if native modules need to be (re)built, my console will revert back to raster fonts. Thankfully, I no longer have to reset the fonts every single time I open the terminal, only when running node-gyp.

claunia commented

@SteveL-MSFT commented on GitHub (May 23, 2019):

PSReadLine 2.0.0-beta4 was published that should address many issues (although it has a few new ones) . https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@SteveL-MSFT commented on GitHub (May 23, 2019): PSReadLine 2.0.0-beta4 was published that should address many issues (although it has a few new ones) . https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

claunia commented

@danielniccoli commented on GitHub (Jun 15, 2019):

@SteveL-MSFT 2.0.0-beta4 didn't fix this bug.

@danielniccoli commented on GitHub (Jun 15, 2019): @SteveL-MSFT 2.0.0-beta4 didn't fix this bug.

claunia commented

@SailorMax commented on GitHub (Jun 27, 2019):

I use regular CMD terminal with git's bash.exe + phpunit = same problem. It appear after few seconds of script start working.
Not sure the reason in PowerShell...

@SailorMax commented on GitHub (Jun 27, 2019): I use regular CMD terminal with git's bash.exe + phpunit = same problem. It appear after few seconds of script start working. Not sure the reason in PowerShell...

claunia commented

@ghost commented on GitHub (Jul 24, 2019):

@SteveL-MSFT 2.0.0-beta4 does not fix the bug for me either.

@sebgod Thanks for the tip, I've switched from Consolas 16 to Lucida Console 14, it's about the same to my eyes.

@ghost commented on GitHub (Jul 24, 2019): @SteveL-MSFT 2.0.0-beta4 does not fix the bug for me either. @sebgod Thanks for the tip, I've switched from Consolas 16 to Lucida Console 14, it's about the same to my eyes.

claunia commented

@SteveL-MSFT commented on GitHub (Jul 25, 2019):

I'll have someone look into this again

@SteveL-MSFT commented on GitHub (Jul 25, 2019): I'll have someone look into this again

claunia commented

@ghost commented on GitHub (Jul 30, 2019):

@SteveL-MSFT To replicate this, open a command prompt, set your font to Consolas,
and then run cmd /c chcp 65001 >NUL && powershell

@ghost commented on GitHub (Jul 30, 2019): @SteveL-MSFT To replicate this, open a command prompt, set your font to Consolas, and then run `cmd /c chcp 65001 >NUL && powershell`

claunia commented

@SteveL-MSFT commented on GitHub (Aug 3, 2019):

Ok, I think I identified the actual issue and it doesn't have anything to do with PSReadLine. There is a check in Windows PowerShell to see if the code page is supported by the Consolas font. The list is here. UTF-8 65001 isn't in that list, so whenever Windows PowerShell identifies a code page that isn't supported by Consolas, it will change the font to Terminal. PowerShell Core 6.x doesn't have this code anymore so you don't see this behavior. I'm hesitant of changing this code as it may break something else. For my own notes, this is in ConsoleControl.cs line 2648.

@SteveL-MSFT commented on GitHub (Aug 3, 2019): Ok, I think I identified the actual issue and it doesn't have anything to do with PSReadLine. There is a check in Windows PowerShell to see if the code page is supported by the Consolas font. The list is [here](https://docs.microsoft.com/en-us/typography/font-list/consolas). UTF-8 65001 isn't in that list, so whenever Windows PowerShell identifies a code page that isn't supported by Consolas, it will change the font to `Terminal`. PowerShell Core 6.x doesn't have this code anymore so you don't see this behavior. I'm hesitant of changing this code as it may break something else. For my own notes, this is in ConsoleControl.cs line 2648.

claunia commented

@sebgod commented on GitHub (Aug 3, 2019):

Ok, I think I identified the actual issue and it doesn't have anything to do with PSReadLine. There is a check in Windows PowerShell to see if the code page is supported by the Consolas font. The list is here. UTF-8 65001 isn't in that list, so whenever Windows PowerShell identifies a code page that isn't supported by Consolas, it will change the font to Terminal. PowerShell Core 6.x doesn't have this code anymore so you don't see this behavior. I'm hesitant of changing this code as it may break something else. For my own notes, this is in ConsoleControl.cs line 2648.

Not sure how can this break something, as UTF-8 was not supported prior to the most recent Windows 10 versions.

@sebgod commented on GitHub (Aug 3, 2019): > Ok, I think I identified the actual issue and it doesn't have anything to do with PSReadLine. There is a check in Windows PowerShell to see if the code page is supported by the Consolas font. The list is [here](https://docs.microsoft.com/en-us/typography/font-list/consolas). UTF-8 65001 isn't in that list, so whenever Windows PowerShell identifies a code page that isn't supported by Consolas, it will change the font to `Terminal`. PowerShell Core 6.x doesn't have this code anymore so you don't see this behavior. I'm hesitant of changing this code as it may break something else. For my own notes, this is in ConsoleControl.cs line 2648. Not sure how can this break something, as UTF-8 was not supported prior to the most recent Windows 10 versions.

claunia commented

@SteveL-MSFT commented on GitHub (Aug 3, 2019):

@sebgod break something here means incorrect rendering as I'm sure Consolas doesn't have all the glyphs needed by UTF-8

@SteveL-MSFT commented on GitHub (Aug 3, 2019): @sebgod break something here means incorrect rendering as I'm sure Consolas doesn't have all the glyphs needed by UTF-8

claunia commented

@danielniccoli commented on GitHub (Aug 3, 2019):

@SteveL-MSFT Lucida Console, Courier New and all the other available fonts that are not affected by this issue although they also do not support codepage 65001 either. Coincidentally, Consolas even supports more codepages than Lucida Console. So why does this happen with Consolas only?

But generally speaking, it should be the users decision what font is used for display. If glyphs are not present, they are displayed as � and the user can make a decision to change the font.

@danielniccoli commented on GitHub (Aug 3, 2019): @SteveL-MSFT Lucida Console, Courier New and all the other available fonts that are not affected by this issue although they also do not support codepage 65001 either. Coincidentally, Consolas even supports more codepages than Lucida Console. So why does this happen with Consolas only? But generally speaking, it should be the users decision what font is used for display. If glyphs are not present, they are displayed as `�` and the user can make a decision to change the font.

claunia commented

@God-damnit-all commented on GitHub (Aug 3, 2019):

@Borkason I think it's a very clear-cut issue from a native English-speaker's perspective, but there is no doubt a fear of causing problems for international users that we are not able to foresee.

As an example, when @bitcrazed (another member of the Microsoft Terminal team) introduced a PR to cURL that would implement Windows VT support https://github.com/curl/curl/pull/3011 (which involved changing the code page to 65001), it ended up causing an issue for international users: https://github.com/curl/curl/issues/3211

This necessitated a patch that writes UTF-8 in the current code page using wide string APIs instead: 1d394188c5

It doesn't surprise me that the Microsoft Terminal team is wanting to approach this very carefully after that.

@God-damnit-all commented on GitHub (Aug 3, 2019): @Borkason I think it's a very clear-cut issue from a native English-speaker's perspective, but there is no doubt a fear of causing problems for international users that we are not able to foresee. As an example, when @bitcrazed (another member of the Microsoft Terminal team) introduced a PR to cURL that would implement Windows VT support https://github.com/curl/curl/pull/3011 (which involved changing the code page to 65001), it ended up causing an issue for international users: https://github.com/curl/curl/issues/3211 This necessitated a patch that writes UTF-8 in the current code page using wide string APIs instead: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9 It doesn't surprise me that the Microsoft Terminal team is wanting to approach this very carefully after that.

claunia commented

@sebgod commented on GitHub (Aug 5, 2019):

@sebgod break something here means incorrect rendering as I'm sure Consolas doesn't have all the glyphs needed by UTF-8

OK, there is not a single font supplied by Windows that covers all Glyphs defined in UTF-8. Cmd.exe relies on a technology called font linking to provide rendering for all glyphs.
Prior to the inclusion of setting UTF-8 as the system codepage, one had to use chcp 65001 manually, but it was working properly. The font linking bit has to be done manually in the registry to get it working in any case.

@sebgod commented on GitHub (Aug 5, 2019): > @sebgod break something here means incorrect rendering as I'm sure Consolas doesn't have all the glyphs needed by UTF-8 OK, there is not a single font supplied by Windows that covers all Glyphs defined in UTF-8. Cmd.exe relies on a technology called [font linking](https://docs.microsoft.com/en-us/globalization/input/font-technology#font-linking) to provide rendering for all glyphs. Prior to the inclusion of setting UTF-8 as the system codepage, one had to use ```chcp 65001``` manually, but it was working properly. The font linking bit has to be done manually in the registry to get it working in any case.

claunia commented

@danielniccoli commented on GitHub (Aug 5, 2019):

@ImportTaste I don't think that has anything to do with it. The fallback only comes in effect if Consolas is used. If any other font is used like Lucida Console or Courier New, then this does not happen. At least Lucida Consolas has the same code page support as Consolas, so it's hard to understand why it was done this way. If there would be an issue for international users (and by the way, I am not a native english-speaker like you assume) it would still affect all the users that are not using Consolas.

The way I see it, the fallback shouldn't be there in the first place (see PWSH 6+7) or was implemented sloppy (why only Consolas?).

@SteveL-MSFT And I believe fixing it is not a risk at all, because the bug was introduced only with Windows version 1809 and apparently it's an undocumented change a.k.a. no one knows why specifically it was changed.

@danielniccoli commented on GitHub (Aug 5, 2019): @ImportTaste I don't think that has anything to do with it. The fallback only comes in effect if Consolas is used. If any other font is used like Lucida Console or Courier New, then this does not happen. At least Lucida Consolas has the same code page support as Consolas, so it's hard to understand why it was done this way. If there would be an issue for international users (and by the way, I am not a native english-speaker like you assume) it would still affect all the users that are not using Consolas. The way I see it, the fallback shouldn't be there in the first place (see PWSH 6+7) or was implemented sloppy (why only Consolas?). @SteveL-MSFT And I believe fixing it is not a risk at all, because the bug was introduced only with Windows version 1809 and apparently it's an undocumented change a.k.a. no one knows why specifically it was changed.

claunia commented

@God-damnit-all commented on GitHub (Aug 6, 2019):

@Borkason As I said, it was a relatable example of something unexpected going wrong.

I'm surprised to hear it's supposedly only an 1809 change, I've had issues with the console font changing itself to raster in the past.

@God-damnit-all commented on GitHub (Aug 6, 2019): @Borkason As I said, it was a relatable example of something unexpected going wrong. I'm surprised to hear it's supposedly only an 1809 change, I've had issues with the console font changing itself to raster in the past.

claunia commented

@SteveL-MSFT commented on GitHub (Aug 15, 2019):

It was only detected in 1809 because the default font for the console was Consolas. Prior to that, I believe it was Lucida Console? And the code worked the same way for that font. My understanding of that code (which has been there since forever and prior to my team on the PowerShell Team) is that in the Windows sources, we only have one shortcut used for PowerShell and that shortcut defines the default font. So when the default font was changed, East Asian users complained as their glyphs weren't being rendered since the font doesn't support it. So this code detects that the font and locale aren't compatible and switches it to one that will render.

I'm hesitant on making any changes in Windows PowerShell as even seemingly small changes like this lead to unexpected regressions.

@SteveL-MSFT commented on GitHub (Aug 15, 2019): It was only detected in 1809 because the default font for the console was Consolas. Prior to that, I believe it was Lucida Console? And the code worked the same way for that font. My understanding of that code (which has been there since forever and prior to my team on the PowerShell Team) is that in the Windows sources, we only have one shortcut used for PowerShell and that shortcut defines the default font. So when the default font was changed, East Asian users complained as their glyphs weren't being rendered since the font doesn't support it. So this code detects that the font and locale aren't compatible and switches it to one that will render. I'm hesitant on making any changes in Windows PowerShell as even seemingly small changes like this lead to unexpected regressions.

claunia commented

@bitcrazed commented on GitHub (Aug 21, 2019):

@sebgod & all: A few things here:

Clarifications

There is no single font on any platform that includes every glyph for every code-point that can be represented in UTF-8.
Cmd.exe knows nothing about fonts - Cmd.exe is a shell
Console (ConHost.exe) provides the traditional 'terminal-like' command-line UX in Windows
Console's current text rendering engine does not support font-fallback and cannot render most emoji - try it and you'll see the non-displayable character (question mark in a box)

Terminal & Console

Windows Terminal is our new next-gen Terminal UX. It shares several common components with the in-box Console, plus it adds several new features including a text buffer and text renderer which can/will store and display practically all Unicode glyphs.

These components will, eventually, be re-ingested into the in-box Console, but not until after we've released Terminal v1.0 and they've had time to be well-tested in real world use.

PowerShell

As @SteveL-MSFT points out, PowerShell Core (PSCore) does not exhibit this issue and since PSCore is the future of PowerShell, we encourage you to use it wherever possible.

Changing the behavior of PowerShell for Windows (PS) is potentially difficult because as we know from trying to fix/change the behavior of Cmd, even small seemingly innocuous changes can result in surprising breakage in the real world.

This said, I'll discuss with Steve & Team and we'll explore if PS could be modified to choose a non-raster font (e.g. Consolas/Lucida/etc.) for code-page 65001.

@bitcrazed commented on GitHub (Aug 21, 2019): @sebgod & all: A few things here: ## Clarifications 1. There is no single font on any platform that includes every glyph for every code-point that can be represented in UTF-8. 1. Cmd.exe knows nothing about fonts - Cmd.exe is a shell 1. Console (ConHost.exe) provides the traditional 'terminal-like' command-line UX in Windows 1. Console's current text rendering engine does not support font-fallback and cannot render most emoji - try it and you'll see the non-displayable character (question mark in a box) ## Terminal & Console Windows Terminal is our new next-gen Terminal UX. It shares several common components with the in-box Console, plus it adds several new features including a text buffer and text renderer which can/will store and display practically all Unicode glyphs. These components will, eventually, be re-ingested into the in-box Console, but not until after we've released Terminal v1.0 and they've had time to be well-tested in real world use. ## PowerShell As @SteveL-MSFT points out, PowerShell Core (PSCore) does not exhibit this issue and since PSCore is the future of PowerShell, we encourage you to use it wherever possible. Changing the behavior of PowerShell for Windows (PS) is potentially difficult because as we know from trying to fix/change the behavior of Cmd, even small seemingly innocuous changes can result in surprising breakage in the real world. This said, I'll discuss with Steve & Team and we'll explore if PS could be modified to choose a non-raster font (e.g. Consolas/Lucida/etc.) for code-page 65001.

claunia commented

@sebgod commented on GitHub (Sep 3, 2019):

@sebgod & all: A few things here:

Clarifications

There is no single font on any platform that includes every glyph for every code-point that can be represented in UTF-8.

Yes, that is why I said "there is not a single font supplied by Windows that covers all Glyphs defined in UTF-8"

Cmd.exe knows nothing about fonts - Cmd.exe is a shell

Yes sorry for being lazy I just meant to refer to what happens if you type "cmd.exe" in the Windows search box

Console (ConHost.exe) provides the traditional 'terminal-like' command-line UX in Windows

Console's current text rendering engine does not support font-fallback and cannot render most emoji - try it and you'll see the non-displayable character (question mark in a box)

As I understood the current engine cannot render any characters from higher Unicode planes, which includes (most) emoji characters.

Now I have to be nit picky, I was talking about Font Linking, which is supported or at least working:

By adding the value Lucida Console under key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
with type REG_MULTI_SZ and the following data (or similar, should be monospaced fonts):

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

It is possible to show most Unicode basic plane glyphs when using chcp 65001 or since 1803 by setting the system codepage to UTF-8 (beta but working so far), which I personally prefer to use the specific code pages for each language as I use multiple languages.

Now I prefer to use Consolas which was not working since 1903 due to it switching to raster fonts.

Terminal & Console

Windows Terminal is our new next-gen Terminal UX. It shares several common components with the in-box Console, plus it adds several new features including a text buffer and text renderer which can/will store and display practically all Unicode glyphs.

These components will, eventually, be re-ingested into the in-box Console, but not until after we've released Terminal v1.0 and they've had time to be well-tested in real world use.

Yes I have used the new Terminal UX already and it is of course extremely pleasant to use, but it does not allow to input Chinese characters at the moment (I hope this will be fixed eventually)

PowerShell

As @SteveL-MSFT points out, PowerShell Core (PSCore) does not exhibit this issue and since PSCore is the future of PowerShell, we encourage you to use it wherever possible.

Changing the behavior of PowerShell for Windows (PS) is potentially difficult because as we know from trying to fix/change the behavior of Cmd, even small seemingly innocuous changes can result in surprising breakage in the real world.

This said, I'll discuss with Steve & Team and we'll explore if PS could be modified to choose a non-raster font (e.g. Consolas/Lucida/etc.) for code-page 65001.

@sebgod commented on GitHub (Sep 3, 2019): > @sebgod & all: A few things here: > > ## Clarifications > 1. There is no single font on any platform that includes every glyph for every code-point that can be represented in UTF-8. Yes, that is why I said "there is not a single font supplied by Windows that covers all Glyphs defined in UTF-8" > 2. Cmd.exe knows nothing about fonts - Cmd.exe is a shell Yes sorry for being lazy I just meant to refer to what happens if you type "cmd.exe" in the Windows search box > 3. Console (ConHost.exe) provides the traditional 'terminal-like' command-line UX in Windows > 4. Console's current text rendering engine does not support font-fallback and cannot render most emoji - try it and you'll see the non-displayable character (question mark in a box) As I understood the current engine cannot render any characters from higher Unicode planes, which includes (most) emoji characters. Now I have to be nit picky, I was talking about Font Linking, which is supported or at least working: By adding the value ```Lucida Console``` under key ```HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink``` with type ```REG_MULTI_SZ``` and the following data (or similar, should be monospaced fonts): ``` 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 ``` It is possible to show most Unicode basic plane glyphs when using ```chcp 65001``` or since 1803 by setting the system codepage to UTF-8 (beta but working so far), which I personally prefer to use the specific code pages for each language as I use multiple languages. ![image](https://user-images.githubusercontent.com/2624915/64138335-05ad8f00-ce40-11e9-8a60-4fc1541e636a.png) Now I prefer to use Consolas which was not working since 1903 due to it switching to raster fonts. > > ## Terminal & Console > Windows Terminal is our new next-gen Terminal UX. It shares several common components with the in-box Console, plus it adds several new features including a text buffer and text renderer which can/will store and display practically all Unicode glyphs. > > These components will, eventually, be re-ingested into the in-box Console, but not until after we've released Terminal v1.0 and they've had time to be well-tested in real world use. > Yes I have used the new Terminal UX already and it is of course extremely pleasant to use, but it does not allow to input Chinese characters at the moment (I hope this will be fixed eventually) > ## PowerShell > As @SteveL-MSFT points out, PowerShell Core (PSCore) does not exhibit this issue and since PSCore is the future of PowerShell, we encourage you to use it wherever possible. > > Changing the behavior of PowerShell for Windows (PS) is potentially difficult because as we know from trying to fix/change the behavior of Cmd, even small seemingly innocuous changes can result in surprising breakage in the real world. > > This said, I'll discuss with Steve & Team and we'll explore if PS could be modified to choose a non-raster font (e.g. Consolas/Lucida/etc.) for code-page 65001.

claunia commented

@sergei-bondarenko commented on GitHub (Oct 25, 2019):

If changes can break something and we even can not know what exactly, so nothing can be changed in the terminal ever again?

@sergei-bondarenko commented on GitHub (Oct 25, 2019): If changes can break something and we even can not know what exactly, so nothing can be changed in the terminal ever again?

claunia commented

@edyu commented on GitHub (Nov 20, 2019):

I "fixed" the problem by using Powershell Core. I first noticed that none of the Powershell settings does anything (but it did change the settings on cmd.exe). After a couple hours of trying different things I stumpled upon Powershell Core and as soon as I downloaded it, the settings I saved before took effect as soon as I opened the Powershell core preview.

@edyu commented on GitHub (Nov 20, 2019): I "fixed" the problem by using Powershell Core. I first noticed that none of the Powershell settings does anything (but it did change the settings on cmd.exe). After a couple hours of trying different things I stumpled upon Powershell Core and as soon as I downloaded it, the settings I saved before took effect as soon as I opened the Powershell core preview.

claunia commented

@CHerSun commented on GitHub (Apr 1, 2020):

Got the same issue while running some of commands (including scoop) from FAR manager - this effect just ruins how FAR is shown. Happens only with Consolas font and beta option enabled to use UTF-8 (65001) codepage in console. My locale is Russian.

As end-user - It's really annoying when program tries to be smarter than me. I can live with question marks instead of some of UTF-8 symbols, but this font changing just ruins display of programs that shouldn't be affected at all, like FAR manger. This is a pain.

For now I had to revert to Russian locale for console (back from UTF-8), yet this limits working with files named using symbols of other locales. I hope you can remove that special Consolas treating.

@CHerSun commented on GitHub (Apr 1, 2020): Got the same issue while running some of commands (including scoop) from FAR manager - this effect just ruins how FAR is shown. Happens only with Consolas font and beta option enabled to use UTF-8 (65001) codepage in console. My locale is Russian. As end-user - It's really annoying when program tries to be smarter than me. I can live with question marks instead of some of UTF-8 symbols, but this font changing just ruins display of programs that shouldn't be affected at all, like FAR manger. This is a pain. For now I had to revert to Russian locale for console (back from UTF-8), yet this limits working with files named using symbols of other locales. I hope you can remove that special Consolas treating.

claunia commented

@dermoritz commented on GitHub (Apr 12, 2020):

I have the same issue but only if i try to use consolas. probably @SteveL-MSFT is right.
I tried Lucida Console and this is working fine. So i guess Consolas is missing some glyphs for utf-8 (my codepage)?!
Powershell Core 7 works fine with all fonts.

@dermoritz commented on GitHub (Apr 12, 2020): I have the same issue but only if i try to use consolas. probably @SteveL-MSFT is right. I tried Lucida Console and this is working fine. So i guess Consolas is missing some glyphs for utf-8 (my codepage)?! Powershell Core 7 works fine with all fonts.

claunia commented

@marcelomgarcia commented on GitHub (May 23, 2020):

Incredible, I bought a Windows laptop in 2020 (xps15) and I have the same issue. Probably hundreds of Windows updates later, and the problem persist. If PS Core was the future in 2019, why is not installed in 2020? The PS Core could be default, and maybe the old PS could be installed as fall back in case some one need for compatibility issue. Anyway, I installed the Windows Terminal and let's try it.

@marcelomgarcia commented on GitHub (May 23, 2020): Incredible, I bought a Windows laptop in 2020 (xps15) and I have the same issue. Probably hundreds of Windows updates later, and the problem persist. If PS Core was the future in 2019, why is not installed in 2020? The PS Core could be default, and maybe the old PS could be installed as fall back in case some one need for compatibility issue. Anyway, I installed the Windows Terminal and let's try it.

claunia commented

@doctordns commented on GitHub (May 23, 2020):

@marcelomgarcia FWIW, the reason that PowerShell 7 is not installed in Windows by default is due to support and liability issues. Windows and PowerShell 7 have different support and so far as I can tell, the lawyers have not figured out a way to do it. For now, anyway. I am sure that everyone would love to see PowerShell 7 shipped inside Windows 10 or Windows Server.

Rember: Windows PowerShell is a core component of Windows 10 and the default installer adds it to your installed on your laptop. It is a fully supported component FWIW. IF you want PowerShell 7, however, that is a separate and non-integrated installation process.

What language is your computer?

@doctordns commented on GitHub (May 23, 2020): @marcelomgarcia FWIW, the reason that PowerShell 7 is not installed in Windows by default is due to support and liability issues. Windows and PowerShell 7 have different support and so far as I can tell, the lawyers have not figured out a way to do it. For now, anyway. I am sure that everyone would love to see PowerShell 7 shipped inside Windows 10 or Windows Server. Rember: Windows PowerShell is a core component of Windows 10 and the default installer adds it to your installed on your laptop. It is a fully supported component FWIW. IF you want PowerShell 7, however, that is a separate and non-integrated installation process. What language is your computer?

claunia commented

@marcelomgarcia commented on GitHub (May 23, 2020):

Thanks for the explanation @doctordns. It's just somewhat frustrating issue, and for someone outside seems to be a "simple" problem. I'm install PowerShell 7.

I use English US.

@marcelomgarcia commented on GitHub (May 23, 2020): Thanks for the explanation @doctordns. It's just somewhat frustrating issue, and for someone outside seems to be a "simple" problem. I'm install PowerShell 7. I use English US.

claunia commented

@alex-jitbit commented on GitHub (Jun 4, 2021):

Observation: if you have a BAT file where you call powershell script.ps1 two times the second call resets font to raster.

Inserting chcp 437 between the calls helps.

More info https://superuser.com/questions/706562/why-does-running-powershell-change-my-console-font

@alex-jitbit commented on GitHub (Jun 4, 2021): Observation: if you have a BAT file where you call `powershell script.ps1` two times the *second* call resets font to raster. Inserting `chcp 437` between the calls helps. More info https://superuser.com/questions/706562/why-does-running-powershell-change-my-console-font

claunia commented

@God-damnit-all commented on GitHub (Jun 5, 2021):

Observation: if you have a BAT file where you call powershell script.ps1 two times the second call resets font to raster.

I've confirmed it and I can see why this happens. Here's a script that illustrates the issue (and I tossed in my sleep function for funsies):

@echo off && @echo|set /p="chcp; Write-Host "$args run complete"" > "%TEMP%\test.ps1"

echo/This test assumes your default code page is 437 and your console font is set to Consolas (or another font that the raster font bug occurs with)
call:sleep 5
echo/
echo/This should say the active code page is 437 . . .
chcp
call:sleep 3
echo/
echo/Running test.ps1 for the first time . . .
call:sleep .25
powershell.exe -ExecutionPolicy Unrestricted -File "%TEMP%\test.ps1" "First"
call:sleep 3
echo/
echo/As you can see, the code page in PowerShell was changed to 65001, but after exiting, it still persists . . .
call:sleep 1.5
chcp
call:sleep 3
echo/
echo/Now, watch what happens when we go into PowerShell with the code page already set to 65001 . . .
call:sleep 4
echo/
echo/Running test.ps1 for the second time . . .
call:sleep .25
powershell.exe -ExecutionPolicy Unrestricted -File "%TEMP%\test.ps1" "Second"
del "%TEMP%\test.ps1"
call:sleep 3
echo/
echo/Assuming the bug is replicated, the console is now using a raster font
call:sleep 3
echo/
echo/This concludes the test
call:sleep 1.5
echo/
echo|set /p="[Done]" & runas /user:# "" >NUL 2>&1
exit /b0

::Sleep function
:sleep
setlocal EnableDelayedExpansion
set x=%1.
set dec=%x:*.=%
set int=!x:.%dec%=!
set dec=%dec:.=%
set dec=%dec:~0,3%
if "%dec%"==".=" set dec=1000
if "%dec%"=="~0,3" set dec=1000
if %dec% LSS 10 set dec=%dec%00
if %dec% LSS 100 set dec=%dec%0
ping 203.0.113.0 -n 1 -w %int%%dec:~-3% >NUL
endlocal

Inserting chcp 437 between the calls helps.

You can also put chcp 437 >$NULL in the ps1 file to prevent it as well.

@God-damnit-all commented on GitHub (Jun 5, 2021): > Observation: if you have a BAT file where you call `powershell script.ps1` two times the _second_ call resets font to raster. I've confirmed it and I can see why this happens. Here's a script that illustrates the issue (and I tossed in my sleep function for funsies): ```cmd @echo off && @echo|set /p="chcp; Write-Host "$args run complete"" > "%TEMP%\test.ps1" echo/This test assumes your default code page is 437 and your console font is set to Consolas (or another font that the raster font bug occurs with) call:sleep 5 echo/ echo/This should say the active code page is 437 . . . chcp call:sleep 3 echo/ echo/Running test.ps1 for the first time . . . call:sleep .25 powershell.exe -ExecutionPolicy Unrestricted -File "%TEMP%\test.ps1" "First" call:sleep 3 echo/ echo/As you can see, the code page in PowerShell was changed to 65001, but after exiting, it still persists . . . call:sleep 1.5 chcp call:sleep 3 echo/ echo/Now, watch what happens when we go into PowerShell with the code page already set to 65001 . . . call:sleep 4 echo/ echo/Running test.ps1 for the second time . . . call:sleep .25 powershell.exe -ExecutionPolicy Unrestricted -File "%TEMP%\test.ps1" "Second" del "%TEMP%\test.ps1" call:sleep 3 echo/ echo/Assuming the bug is replicated, the console is now using a raster font call:sleep 3 echo/ echo/This concludes the test call:sleep 1.5 echo/ echo|set /p="[Done]" & runas /user:# "" >NUL 2>&1 exit /b0 ::Sleep function :sleep setlocal EnableDelayedExpansion set x=%1. set dec=%x:*.=% set int=!x:.%dec%=! set dec=%dec:.=% set dec=%dec:~0,3% if "%dec%"==".=" set dec=1000 if "%dec%"=="~0,3" set dec=1000 if %dec% LSS 10 set dec=%dec%00 if %dec% LSS 100 set dec=%dec%0 ping 203.0.113.0 -n 1 -w %int%%dec:~-3% >NUL endlocal ``` > Inserting `chcp 437` between the calls helps. You can also put `chcp 437 >$NULL` in the ps1 file to prevent it as well.

claunia commented

@alabuzhev commented on GitHub (Jul 24, 2021):

when the default font was changed, East Asian users complained as their glyphs weren't being rendered since the font doesn't support it. So this code detects that the font and locale aren't compatible and switches it to one that will render.

@SteveL-MSFT, after #10472 & #10477 this is no longer the case - Consolas should be able to render everything.
You might want to reconsider this and other similar workarounds, if any.

@alabuzhev commented on GitHub (Jul 24, 2021): > when the default font was changed, East Asian users complained as their glyphs weren't being rendered since the font doesn't support it. So this code detects that the font and locale aren't compatible and switches it to one that will render. @SteveL-MSFT, after #10472 & #10477 this is no longer the case - Consolas should be able to render everything. You might want to reconsider this and other similar workarounds, if any.

claunia commented