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
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:
Expected behavior
Actual behavior
Environment data