3 ms·

Personally I want to use PowerShell. The show-stopper for me is that I cannot set default encoding for output redirection (>) to ascii/utf-8. This is so import

Personally I want to use PowerShell. The show-stopper for me is that I cannot set default encoding for output redirection (>) to ascii/utf-8. This is so important for things like Google Code Jam, etc.

ygra 10y ago
I agree it's annoying¹, but I wouldn't call it a show-stopper. I have resorted to Out-File -Encoding <foo> wherever I need file output. _________________ ¹ The redirection syntax cannot easily accommodate an encoding, so in general you cannot really use it everywhere anyway. I often need to use the system's legacy codepage instead of Unicode, so UTF-8 by default would be just as useless there. GCJ, however, could just accept text in any common encoding instead of insisting on ASCII. Detecting UTF-16 isn't hard, even though common Unix tools tend to treat it as arbitrary binary data instead of text. Generally I'd say > is a convenience feature more than an actually useful construct, at least in a shell like PowerShell. On Unix-likes > simply dumps bytes since that's what the shell is built around. For PowerShell you could just as well say you'd dump CLIXML instead, since the shell works with objects. Since you have a few valid options you could either try to shoehorn them into the syntax, either with various funny characters Get-Data > data-as-utf8.txt Get-Data >@ data-as-clixml.xml Get-Data >% data-as-utf16.txt ... or add another expression somewhere Get-Data > data-as-utf8.txt,[Text.Encoding]::Utf8 all of which are options I'd say don't really fit into PowerShell, nor should they be entertained. Does it really matter whether the last part of a pipeline is a redirection operator or just a terminating command that writes the data to a file? Conceptually I'd say having the pipeline end in a pipeline element instead of something entirely else is preferable since it reduces the number of distinct concepts.
JeffreySnover 10y ago
Here is how you do that: $PSDefaultParameterValues["Out-File:Encoding"]="utf8" Jeffrey Snover [MSFT]

ygra 10y ago

I agree it's annoying¹, but I wouldn't call it a show-stopper. I have resorted to Out-File -Encoding <foo> wherever I need file output. _________________ ¹ The redirection syntax cannot easily accommodate an encoding, so in general you cannot really use it everywhere anyway. I often need to use the system's legacy codepage instead of Unicode, so UTF-8 by default would be just as useless there. GCJ, however, could just accept text in any common encoding instead of insisting on ASCII. Detecting UTF-16 isn't hard, even though common Unix tools tend to treat it as arbitrary binary data instead of text. Generally I'd say > is a convenience feature more than an actually useful construct, at least in a shell like PowerShell. On Unix-likes > simply dumps bytes since that's what the shell is built around. For PowerShell you could just as well say you'd dump CLIXML instead, since the shell works with objects. Since you have a few valid options you could either try to shoehorn them into the syntax, either with various funny characters Get-Data > data-as-utf8.txt Get-Data >@ data-as-clixml.xml Get-Data >% data-as-utf16.txt ... or add another expression somewhere Get-Data > data-as-utf8.txt,[Text.Encoding]::Utf8 all of which are options I'd say don't really fit into PowerShell, nor should they be entertained. Does it really matter whether the last part of a pipeline is a redirection operator or just a terminating command that writes the data to a file? Conceptually I'd say having the pipeline end in a pipeline element instead of something entirely else is preferable since it reduces the number of distinct concepts.

JeffreySnover 10y ago

Here is how you do that: $PSDefaultParameterValues["Out-File:Encoding"]="utf8" Jeffrey Snover [MSFT]