oh-my-posh: Path encoding problem on chinese charactor.

Prerequisites

  • I have read and understand the CONTRIBUTING guide
  • I looked for duplicate issues before submitting this one

Description

Path encoding problem on Set-PoshPrompt.

&: The term 'C:\Users\sheey\OneDrive\鏂囨。\PowerShell\Modules\oh-my-posh\3.120.1\bin\posh-windows-amd64.exe'
is not recognized as a name of a cmdlet, function, script file, or executable program.

The string 鏂囨。 should be 文档, or Document in English.

Environment

  • Oh my Posh version: 3.120.1
  • Theme: haven’t set yet
  • Operating System: Windows 10
  • Shell: pwsh
  • Terminal: windows-terminal

Steps to Reproduce

Set-PoshPrompt -Theme agnosterplus

Expected behavior: Set theme.

Actual behavior: Got error.


I changed oh-my-posh.psm1 to see if it’s the pwsh has wrong encoding.

# near line 59
$poshCommand = Get-PoshCommand
Write-Output $poshCommand # I added this to print the path
Invoke-Expression (& $poshCommand --init --shell=pwsh --config="$config")

but it displayed characters correctly.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 18 (8 by maintainers)

Commits related to this issue

Most upvoted comments

I solved it by setting Windows encoding to UTF8. See stackoverflow.

It passed a quick test on a fresh Chinese VM.

image

@gerardog oh my. Thank you so much for this!

@gerardog allow me to do some tests, it’s been a while and conhost also went through some changes. If it works on my machines, I’ll do as proposed because I agree, we shouldn’t have to do this.

Hi Jan. I had some encoding issues with pwsh which lead me to force utf-8 on gerardog/gsudo. I found out that:

I configured a virtual machine and installed GBK as default language and now I have seen what the problem is.

I learned that changing the “current process” encoding inside one app (For example Console.InputEncoding = System.Text.Encoding.UTF8), also changes the console-host code page, and that change stays even after the app the closed.

Also the whole console window changes its font and language the moment the codepage is changed to 65001 (utf-8). CMD language changes, and what encoding is assumed for files without BOM…

So, I decided that gsudo should not change the codepage. If an encoding problem occurs, that should be addressed by each user… English users are safe to change to utf-8 without consequences, but others don’t.

Ultimately found out it was not pwsh but oh-my-posh who was changing the encoding. I’ve captured oh-my-posh --print-init and put that literal into my $profile without the encoding. I saw oh-my-posh fully functional when using a proper font. I understand there must be other issues if you don’t change the encoding. But at least my take on it is that it should be the user who changes the encoding knowingly and probably do it in a full user scope, given that if one process changes the encoding, it also changes the code page for the current console, even if you close PowerShell.

In that direction, what about adding a setting to disable any encoding change ? Something the user could put in their profiles before oh-my-posh, like…

 if ($ExecutionContext.SessionState.LanguageMode -ne "ConstrainedLanguage" -and -not $OhMyPoshSkipEncodingChange) {
     [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding
 }

Thanks, and great work with oh-my-posh. I Love it and use it everyday.

I have same problem and @Sheey11 's method also works for me.

I had the same problem with Set-PoshPrompt on a Danish laptop with Ø in the posh path. Solved by changing to beta UTF-8 mode as per the SO link from @Sheey11 .