Can't set different font for the terminal

[trainto]

When I change font via setting menu of Bash on Ubuntu on Windows terminal, it's applied. But close the terminal and relaunch it, then it goes to default font. However in case of background colour setting, it keeps what I set before.

Is ther anyone who went through this situation?

[clarkzjw]

@trainto It seems current build has this problem indeed.

However, you can use some third party tools like ConEmu. The latest version of ConEmu can use bash on Windows out-of-box. And it comes with tons of configurations as you can imagine, fonts and themes setting of course.

[onomatopellan]

I changed yesterday the font of Bash on Ubuntu on Windows to DejaVuSansMono.ttf and today font is still applied.
Could it be you changed it while being in an admin bash and now the normal bash doesn't apply the change?

[clarkzjw]

@onomatopellan Whether I change the font in an admin bash or a normal bash, the font falls back to default as long as I open a new bash console.

I changed fonts via: Right click on the title bar -> Properties -> Font.

[onomatopellan]

Correct, I did it same way. It's a clean install too?

[clarkzjw]

@onomatopellan Well, it's not. I upgraded from Windows 10 version 1511.

Maybe that is the reason?

[onomatopellan]

It could. Old CMD version stored changes on registry and they could conflict with the new CMD. You can try to right click title bar -> enable Defaults and try again.

The Ubuntu guy also explained how he had to use regedit to install Ubuntu font in old CMD versions.
http://blog.dustinkirkland.com/2016/04/howto-ubuntu-on-windows.html

[clarkzjw]

Well, maybe I know the reason why.

There are two ways to open bash.

1. Press Win + R, enter "cmd.exe" then press enter, and enter "bash".
2. Click Windows search, enter "bash" and then enter.

Method 1 launches bash within from cmd.exe, while method 2 launches bash.exe directly( Correct me if I am wrong ). You can set fonts in both methods, but method 1 keeps your setting and method 2 loses.

So it seems method 1 sets fonts for cmd.exe while method 2 sets fonts for bash.exe. I was using method 2 all the time. And the font config keeps losing. I tried method 1 just now, and the font config keeps.

[onomatopellan]

I can confirm that. CMD didn't apply DejaVu font like bash did.

[bitcrazed]

@clarkzjw Could I ask you to repro the following steps:

1. Upgrade to Win10AU if you've not already
2. Open cmd from the start menu (non-elevated). Set its font to Consolas
3. Close cmd window
4. Reopen the cmd window from the start menu (non-elevated). It should have the same font as selected in 2.

Note that if you run Win + R -> cmd, you're running cmd.exe, which has a different set of properties to the shortcut used by the start-menu when you find and open the console from the start menu.

And if you open cmd or Command Line (start menu tile) or PowerShell and THEN run bash from within that console, Bash's font properties aren't used - just the fonts preferred by the console you first opened.

• @zadjii-msft & @paulcam206 for visibility 😉

[clarkzjw]

@bitcrazed Exactly. I just followed your step. It seems the Command Prompt in Step 2 and cmd.exe via Win + R are different. I didn't noticed that before. Are they different before Win10AU?

[zadjii-msft]

@clarkzjw cmd.exe and Command Prompt are the same thing, but they are loaded slightly differently, so they each have separately stored properties (it's confusing, but legacy, behavior).

Changing the properties on a bash window launched from the start menu (Win Key -> "bash") should persist the properties, but again, separately from the properties of Win Key + R -> "bash".

Perhaps you're setting the "Defaults" and not the "Properties"? These are again, different (and complicated for legacy reasons), and in my experience, changing the "Properties" is the option you always want.

[clarkzjw]

@zadjii-msft Well, things become more interesting after some additional tests.

First, I am pretty sure I am editing Properties, not Defaults. If I use Win Key -> "bash" to launch a bash window, and change the fonts in Properties. and type exit to close and reopen in the same way. I tried some different fonts, it seems some fonts can persist while some cannot.

But if I use Win Key + R -> bash to launch a bash window, and change font settings, in my tests, all fonts can persist, including the fonts failed in (Win Key -> "bash") case.

It's quite interesting. I am not sure if this is what you mean they are loaded slightly differently.

[lnyng]

I think the difference is due to using shortcut or not, but not depends on using cmd or not.
You can go to system32 and double click the bash.exe instance, and it behaviors exactly the same as opening it through cmd. But when you use shortcut, it's different. (at least for me)

By different I mean both the font as and a coloring issue. This is the PS1 I am using:

\n${debian_chroot:+($debian_chroot)}\[\033[38;5;226m\]\u\[$(tput sgr0)\]\[\033[38;5;39m\]@\[$(tput sgr0)\]\[\033[38;5;46m\]\h\[$(tput sgr0)\]\[\033[38;5;15m\]:\[$(tput sgr0)\]\[\033[38;5;87m\]\w\[$(tput sgr0)\]\[\033[38;5;28m\]\\$

It seems that only the bash launched through shortcut could display the color of the PS1 correctly. That's why I want to fix the font problem when using the Win Key + bash (shortcut) way to launch bash.

[zadjii-msft]

@clarkzjw That's strange to me. I'm gonna ping @bitcrazed and @paulcam206 (who has a bit more experience with the properties loading) to see if we can't triage this

@LeonYang5114 Are the colors on the "Colors" properties tab the same for both your bash.exe shortcut and launching it from Win+R the same? This is a bit of what I meant by they are loaded slightly differently - Launching from the shortcut stores the properties in the shortcut itself which the shortcut reads on future relaunches, while launching from Win+R launches the exe directly, reading&writing the properties from the registry.

Because the console doesn't support 256-color in the AU, \033[38;5;226m will get translated into the nearest color in the color table to color 266, so if you have different color tables, it will get translated differently depending on what's available. You can see #76 for more on this.

[gurnec]

FWIW I just ran into what I believe is a general Windows console bug which I at first thought was WSL related, but no longer do. I'm just pointing it out on the off chance it's being encountered by anyone watching this issue.

To reproduce (on Win10AU):

1. Open the font properties (via any method), change the font size to something that's not in the font size list (e.g. 15) by typing it into the provided edit box, OK out. (The size will change as expected.)
2. Open the font properties again. You'll see that 15 has been added to the font size list and it's pre-selected. Leave it alone, choose a different font, and OK out. The font should change as requested, however it doesn't (and the new setting isn't persisted).

For whatever reason, if that 15 temporarily added to the list box remains selected, font changes are ignored.

The workaround is to ensure the 15 in the list box isn't selected before OKing out, either by selecting a different size or by entering 15 in the edit box.

My apologies for the noise it this is unrelated...

[spivoler]

Hi Guys,

I am having exactly the same problem. The only thing I wanted to do is to use font consolas and save it as default. That used to work until after I install language package (Simplified Chinese). After that, the default font is always a Chinese font. I can manually change the font of current bash, while the setting cannot be saved for future usage...

It would be good to have the bug fixed asap. Appreciate it.

[mchenzero]

I have this same issue too. I figured that this may only happen to Asian installations.

Asian installations have different fonts available for use in a console session window than non Asian installations. (See the explanation here.)

While, for example, Consolas is available for use in console for non Asian installations (yes?), it is not shown in the font list of Command Prompt's properties setting window for Asian installations. However, it is shown and usable in Bash on Ubuntu on Windows.

I found that for any fonts shown in Command Prompt's font list, for example MS Gothic, the setting on Bash on Ubuntu on Windows could persist. (A shortcut is needed as pointed out by @LeonYang5114.) But for any fonts not shown in Command Prompt's font list, the font setting on Bash on Ubuntu on Windows only works for the current session. However, if we right click and see properties of the shortcut, we can see that font setting has actually been saved.

[bitcrazed]

@ALL: There are several nuances to how and where console apps get their settings from when launched directly, via start-menu tiles, and via shortcuts / pinned apps. We'll be writing-up a blog post on this v. soon.

For now, remember:

1. If you run a console app directly (e.g. via [Win] + [R] -> console app), its settings are pulled from the registry. If there are no pre-existing settings configured for a console app, its settings are initialized from the console defaults.
2. If you launch a console app from a shortcut or tile, the settings for that app are pulled from the shortcut/tile. If you create your own pinned links to apps, each pinned link can have it's own font, colors, etc.
3. If you make changes to the settings of a system-managed .lnk / shortcut / start menu tile / [Win] + [X] menu item, your settings will be restored to defaults each time you upgrade to a new OS build.

In the screenshot below, you'll notice that the two bash consoles, started via different means, have different fonts:

Same app. Same ConHost terminal, different settings due to different start-mechanisms. This can be a very useful feature if you want to create terminals with different settings for different tasks.

[ryanerwin]

@bitcrazed,

It's been 19 days since you posted, and I hope your blog post is coming soon.

Still don't understand HOW to change the font when launching it via a Live Tile or Pinned app? Strange that it would be different from launching via a shortcut...

At least ConEmu supports Bash for Windows quite well so that's probably the best workaround until we've got clarification.

[andrewfinnell]

@ryanerwin Personally I recommend ALWAYS launching it via a Shortcut. The best way I've found is to Right click on the Start Menu shortcut, Pin to Taskbar, then change those properties. Bash for Windows for Ubuntu (i.e. bash.exe.) needs to Run As Administrator anyways, which can only be done via a shortcut. If it isn't Run As Administrator so many things do not work.

[willise]

@bitcrazed Very looking forward to your post.

[ryanerwin]

@afinnell

Besides ping (which I replace with httping) what else doesn't work without bash.exe being run as administrator? I can't stand that full screen warning each time I launch an app confirming it requires admin access, and I don't want to disable UAC (doesn't sound like a good idea)...

Must admit that it's very strange basic things like mklink can fail in cmd.exe when you're not running with administrator access...

[winteryoung]

Can anyone reopen this issue?

[miniksa]

MSFT: 14907854 filed for additional investigation.

[winteryoung]

The best way to do this is adding a fallback font. Windows has already used the system default font (in the case of East Asia) for non-ascii characters. You just need to make this setting available for users.

[miniksa]

Our current rendering system in the console doesn't support font fallback.

I can work on resolving the persistence of any given font if it is not sticking, but font fallback would require a near complete overhaul of the renderer (which is on the long-term plan, but isn't a bug-size fix.)

[NyaMisty]

@ac-m running from Win+R will solve that issue

[ac-m]

@NyaMisty

Thx.

I just tried it from Win+R, the UbuntuMono font is OK, the SourceCodePro font is still not good.

I'm using a customized font, YaHei mixed with SourceCodePro.
It's OK.

[miniksa]

I've submitted an additional fix today to this issue. It should go out to Insiders sometime in the next few weeks (probably in January since we're about to hit the holiday season in the United States).

@NyaMisty had the best explanation above of why this is happening with the console.

As an example on a Traditional Chinese system, the non-Unicode Codepage will be 950. On any console host start, it will retrieve this value from the system and then load up all your settings and preferences. It will convert the codepage to a charset (https://msdn.microsoft.com/en-us/library/cc194829.aspx) getting the CHINESEBIG5_CHARSET and submit that along with the font name preference to GDI. At that point, GDI will realize that your preferred font might not have CHINESEBIG5_CHARSET as an option and instead fallback to another font that does have CHINESEBIG5_CHARSET as an option. Then the console host startup sequence is complete and we will accept a connection from an application.

The WSL subsystem attaches to the console and immediately changes the codepage through SetConsoleCP (https://docs.microsoft.com/en-us/windows/console/setconsolecp) to 65001 (UTF-8). 65001 doesn't have a particular charset associated with it, but the console host doesn't retry your preferred font face name with GDI at the later time.

What I've done in the fix I just submitted is that we will retry setting your preferred font face name with GDI each time your codepage changes. This should mean that while when the console immediately loads, it may not choose Ubuntu Mono for the few moments when the window displays and is waiting for WSL to attach, that it will retry Ubuntu Mono when it receives the SetConsoleCP(65001) command from the subsystem and it will switch to your preferred font by the time the shell prompt comes up.

[liyuan-rey]

I'm using Chinese-Simplified Win10 version 1709, I have same font issue when run cmd.exe/wsl.exe/bash.exe/ubuntu.exe from Start -> Run...
After specified the codepage to 65001(0xfde9) with regedit like below, the font of terminal can be chosen and persistent.

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe]
"CodePage"=dword:fde9

But if run cmd.exe/wsl.exe/bash.exe/ubuntu.exe or any other console application by a shortcut(*.lnk), the font of terminal fallback to Chinese font SimSun.

I found these information, https://msdn.microsoft.com/en-us/library/dd891330.aspx , does that mean .lnk file have its own codepage information, and if we run a console application through .lnk, system will use codepage in .lnk rather than registry - HKEY_CURRENT_USER\Console\*? Is there any way to change codepage in .lnk file?

[bitcrazed]

@liyuan-rey Yes, shortcuts may contain codepage info.

[Brainor]

Here's how I solve the problem, inspired by @liyuan-rey .
My situation: using Chinese-Simplified Win10 version 1709, using Run->Bash to invoke bash interface. The font can't be changed to Consolas permanently.
Solution: Run->regedit, in the path HKEY_CURRENT_USER\Console\%SystemRoot%_system32_bash.exe, add/modify item CodePage->(DWORD)FDE9(65001)

[bitcrazed]

@ALL: As discussed above, we posted two relevant blogs on this subject:

1. How Console and command-line app settings work
2. The default Console colors have been updated (in current Insider builds)
3. Announcing the Console ColorTool to help you apply color themes to Console instances

The first of these blogs is likely of most interest, and we encourage you to read it through several times to make sure you grok the nuances of how Console finds and loads settings for command-line apps from the registry or from shortcuts (inc. shortcuts on the start menu, or pinned to your taskbar/desktop).

Note that the discussion about settings is orthogonal to the Console's current inability to display a broad range of international characters, symbols, and glyphs: That's an entirely different issue that we are keen to address. Please bear with us for now.

[bitcrazed]

@liyuan-rey - If you modify the default codepage of cmd.exe in the registry, it'll likely be ignored when you start Cmd from a start menu or pinned shortcut because Console is reading the codepage set in the shortcut itself, and not bothering to look at the registry because shortcut settings override registry settings.

[liyuan-rey]

@bitcrazed
Yes. And I failed to find tools to adjust codepage settings of the shortcut, I only use [Win+R] to start the console now. 😞

[xqdoo00o]

@Brainor @liyuan-rey
in the path HKEY_CURRENT_USER\Console\C:_Program Files_WindowsApps_CanonicalGroupLimited.UbuntuonWindows_xxxx.ubuntu.exe,
add CodePage->(DWORD)FDE9(65001)
then I start Ubuntu directly from start menu, It's Consolas !
PS: I use the new Ubuntu distribution from windows appstore, not the old one from Windows Subsystem for Linux

[bitcrazed]

@xqdoo00o This should be unnecessary - when you launch a Linux/WSL Console, the codepage is automatically set to UTF-8 anyhow.

Execute the following from within your Linux instance's Console:

$ cmd.exe /C chcp
Active code page: 65001

[AGiantPanda]

I use the ubuntu app from windows store now, my code page is 65001 after running cmd.exe /C chcp command.

In default settings I can set font to consolas, but everytime I run ubuntu from windows start the font is still Chinese font SimSun

[xqdoo00o]

@PaaandaChen you could follow the setup that I published 9 days ago。

[AGiantPanda]

@xqdoo00o
that works, many thanks to you XDDD
didn't watch this issue for a long time.

[bitcrazed]

Thanks for the discussion regarding this issue. Closing for now since there are several solutions to the posted issues.

Please open an issue on the Console Issues repo if you have continued/related issues.

[zhuzisheng]

Here's how I solve the problem, inspired by @liyuan-rey .
My situation: using Chinese-Simplified Win10 version 1709, using Run->Bash to invoke bash interface. The font can't be changed to Consolas permanently.
Solution: Run->regedit, in the path HKEY_CURRENT_USER\Console\%SystemRoot%_system32_bash.exe, add/modify item CodePage->(DWORD)FDE9(65001)

this workaround is nice. Works perfectly on my side.
Thanks a lot!

[jbonnier]

How is this issue closed the problem seems to still be there on a fresh Windows 11 (23H2 Build 22631.4037) install