It seems that powershell.exe support (in Windows) is not fully integrated.
When writing shebang recipes that use non-ASCII characters encoded in UTF-8, the output gets mangled (or more like rendered as gibberish). To support UTF-8 on Windows PowerShell, the output encoding (or codepage) has to be changed in every recipe or the file can be encoded in UTF-8 with BOM. The former is not considered ideal due to its verbose nature, and due to unintended side-effects (changing the codepage affects how the Console Window Host behaves, which means a push/pop strategy has to be used to prevent the encoding change from affecting the "caller" process).
Here's an example:
set quiet := true
default:
#!powershell.exe -NoProfile
Write-Host '🇪🇸 España ♥️💛♥️ just'
Here is the execution result of just default:
En C:\Users\egasato\AppData\Local\Temp\just-D1BjHk\default.ps1: 5 Carácter: 51
+ Write-Host '🇪🇸 España ♥ï¸ðŸ’›â™¥ï¸ just'
+ ~
Falta la cadena en el terminador: '.
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : TerminatorExpectedAtEndOfString
error: Recipe `shebang` failed with exit code 1
Here's the expected result:
It seems that
powershell.exesupport (in Windows) is not fully integrated.When writing shebang recipes that use non-ASCII characters encoded in UTF-8, the output gets mangled (or more like rendered as gibberish). To support UTF-8 on Windows PowerShell, the output encoding (or codepage) has to be changed in every recipe or the file can be encoded in UTF-8 with BOM. The former is not considered ideal due to its verbose nature, and due to unintended side-effects (changing the codepage affects how the Console Window Host behaves, which means a push/pop strategy has to be used to prevent the encoding change from affecting the "caller" process).
Here's an example:
Here is the execution result of
just default:Here's the expected result: