Remote sessions targeting Windows machines unexpectedly use ANSI character encoding for external programs

Note: It is debatable what console encoding should apply when remoting into a Window machine - the caller’s or the target machine’s - but (effectively) using ANSI encoding - rather than the OEM code page, as is still the default on Windows - seems like the wrong choice.

Curiously, Windows PowerShell behaves this way too.

Steps to reproduce

Run on (PS Core) on Windows:

• from an elevated session, to enable “loopback” remoting
• make sure that the calling version is enabled for remoting

& {
  # Target the local machine.
  $htParams = @{ ('HostName', 'ComputerName')[$env:OS -eq 'Windows_NT'] = '.' }
  # On Windows, determine what edition / version to target remotely: use the caller's.
  if ($env:OS -eq 'Windows_NT') {
    $htParams['ConfigurationName'] = (('PowerShell.' + $PSVersionTable.PSVersion), 'microsoft.powershell')[$PSVersionTable.PSEdition -ne 'Core']
  }  
  Invoke-Command @htParams { if ($env:OS -eq 'Windows_NT') { chcp } else { $env:LANG }; [Console]::InputEncoding.WebName; [Console]::OutputEncoding.WebName, $OutputEncoding.WebName }
}

Expected behavior

Active code page: 437
ibm437   # [Console]::InputEncoding.WebName
ibm437   # [Console]::OutputEncoding.WebName
utf-8       # $OutputEncoding

Actual behavior

Active code page: 437
windows-1252   # !! *ANSI* code page
Codepage - 0   # !! *0* - but in effect seems to behave like ANSI
utf-8

Environment data

PowerShell Core 7.2.0-preview.4

[jborean93]

Thanks all for sticking to this and working on a solution.

[jborean93]

Thanks for the PR, I’ve been able to test it and can also confirm it fixes this particular problem. I also couldn’t find any side affects and things acted like they did before.