Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Note:

• This is an unusual scenario, because --% is usually only used with external (native) programs.

• However, PowerShell functions or scripts can meaningfully leverage it by using splatting to relay positional arguments starting with --% to external programs:

• This is yet another manifestation of Objects are situationally invisibly [psobject]-wrapped, sometimes causing unexpected behavior. #5579

# On Windows

function foo {
  $ownArg = $args[0]
  # Using Select-Object causes the problem, due to [psobject]-wrapping the elements.
  $passThruArgs = $args | Select-Object -Skip 1
  # To fix the problem, uncomment the next line.
  # $passThruArgs[0] = $passThruArgs[0].psobject.BaseObject
  cmd /c echo @passThruArgs
}

foo own --% pass these args through, even with broken syntax such as "a or b)

Expected behavior

pass these args through, even with broken syntax such as "a or b)

That is, --% in the array used for splatting should result in the space-concatenated, verbatim list of the remaining arguments to be copied verbatim to the process command line behind the scenes.

Actual behavior

--% "pass these args through, even with broken syntax such as "a or b)"

That is, due to the - invisible and usually inconsequential - [psobject] wrappers created by Select-Object, splatting didn't recognize --% as the stop-parsing token, unexpectedly causing it to be passed on as an argument itself, and the remaining arguments to be enclosed in "...".

Error details

No response

Environment data

PowerShell 7.5.0-preview.1

Visuals

No response