Passing a ScriptBlock (in syntax only) to native commands produces surprising results

Steps to reproduce

Run a command like

echoargs {1}
bcdedit /set {cbd971bf-b7b8-4885-951a-fa03044f5d71} device partition=C:

PowerShell has long assumed that an argument that looks like a ScriptBlock is always a script block - regardless of what command is being called. If the command is native, a very different command line is passed.

This doesn’t make sense for most native commands. Long ago there was a vision that there might be many native commands that supported PowerShell and maybe this made sense then, but that hasn’t happened.

The workaround is to use quotes - not a bad workaround but still shouldn’t be necessary.

If we changed the behavior, we would still pass these special parameters to powershell.exe and pwsh.exe.

Expected behavior

PS> echoargs {1}
arg 0: <{1}>

CommandLine:
EchoArgs.exe {1}

Actual behavior

PS> echoargs {1}
arg 0: <-encodedCommand>
arg 1: <MQA=>
arg 2: <-inputFormat>
arg 3: <xml>
arg 4: <-outputFormat>
arg 5: <text>

CommandLine:
EchoArgs.exe -encodedCommand MQA= -inputFormat xml -outputFormat text

[lzybkr]

I’m suggesting syntax doesn’t matter - if the value is a ScriptBlock, pass the literal text unless calling powershell.exe or pwsh.exe, then use -encodedCommand.

We could attempt to be smart too - only pass the literal if the ScriptBlock has no whitespace, or I suppose escaped whitespace

[yecril71pl]

Could we just limit the encoding to script blocks following -Command or -c? (Unfortunately, -c is rather common, but we must support it anyway.)