You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While you can pass OEM to filesystem cmdlets to support the legacy system locale's OEM code page on Windows, its "ANSI" counterpart (such as Windows 1252 on US-English systems) is currently missing.
(In Windows PowerShell, the Default value fulfills that role, but in PowerShell Core Default now refers to the new default, (BOM-less) UTF-8.)
Therefore, an ANSI encoding value should be introduced to complement the OEM value.
Note: Given that OEM already is available even when running on Unix-like platforms, it sounds like we shouldn't restrict ANSI's availability to Windows. ([System.Text.Encoding]::GetEncoding([cultureinfo]::CurrentCulture.TextInfo.ANSICodePage)seemingly does return a locale-appropriate value on Unix-like platforms as well.)
As discussed in #6550:
While you can pass
OEMto filesystem cmdlets to support the legacy system locale's OEM code page on Windows, its "ANSI" counterpart (such as Windows 1252 on US-English systems) is currently missing.(In Windows PowerShell, the
Defaultvalue fulfills that role, but in PowerShell CoreDefaultnow refers to the new default, (BOM-less) UTF-8.)Therefore, an
ANSIencoding value should be introduced to complement theOEMvalue.With
ANSIavailable, the current workaround:would simply become:
Note: Given that
OEMalready is available even when running on Unix-like platforms, it sounds like we shouldn't restrictANSI's availability to Windows. ([System.Text.Encoding]::GetEncoding([cultureinfo]::CurrentCulture.TextInfo.ANSICodePage)seemingly does return a locale-appropriate value on Unix-like platforms as well.)Environment data
Written as of:
PowerShell Core v6.0.2