Repository navigation
Experimental feature PSNativeCommandArgumentPassing breaks the stop-parsing symbol #15261
Description
Related: #15239, #15250, #15276 - see overview in #15143.
Seemingly, with experimental feature PSNativeCommandArgumentPassing in effect (and preference variable $PSNativeCommandArgumentPassing set to 'Standard'), --%, the stop-parsing symbol is broken in that it is seemingly ignored: escaping of " chars. that follow is now unexpectedly being performed:
Steps to reproduce
[Update: The repro below no longer works, since find has since been put on the list of CLIs that implicitly trigger legacy argument-passing; however, the problem persists - see #18664]
On Windows (Unix is affected too, but --% doesn't make much sense there anyway):
# This worked up to preview 4.
'foo' | find --% /v "" | Should -Be 'foo'Expected behavior
The test should succeed.
Actual behavior
The test fails, because the " chars. are \-escaped:
Access denied - \\
InvalidResult: Expected 'foo', but got $null.
In effect, command line find /v "\"\"" is passed behind the scenes - instead of find /v ""
Note that with without --% the command now works ('foo' | find /v "", which previously failed).
While that is great, --% must not be broken.
Environment data
PowerShell Core 7.2.0-preview.5
Activity
daxian-dbw commentedon Jun 9, 2021
James Truher (@JamesWTruher) Can you please take a look and see if this is by design? If not, please replace the
Needs-Triagelabel withIssue-Bug.rmccampbell commentedon Jun 4, 2022
With some experimentation it looks to me like what is happening is the --% is not really being ignored, but it's being considered as one string literal
and then passed as the first argument (which is then escaped), the same as if you wrotefind '/v ""'.Edit: that wasn't quite correct, it's passing the string as the full command line, but after doing the escaping. So the --% is bypassing powershell parsing, but not bypassing the escaping.
JamesWTruher commentedon Jul 19, 2022
the new behavior enables this scenario directly:
'foo' | find /v ""and the additional--%is not needed.The addition of the
--%creates the second argument as a literal""which is why the misbehavior occurs due to some other code paths. Because the legacy behavior constructs a string to be handed off, the quotes are part of that string. The empty string is (and should be) present in the argument list (new behavior) without the quotes.I have noticed an additional issue because the quoted strings need to passed somewhat untampered with (which is occurring outside the powershell argumentlist handling).
for example:
works just fine, but
does not. In both cases arglist is constructed correctly, and then handed off to the .NET api
I'm suspicious that this may actually be happening in the .net layer as there is some dodgy quote escapement that happens there. This matches the above observations because there is a space in the string, it would need to be quoted so i suspect it is internally. The second case would not need to be quoted and then we see that
find.exegets heartburn.I've not been able to reproduce this with an other
.exe(although my search has not been exhaustive), so it may be best to putfind.exeinto the list oflegacybehavior (along with cmd.exe). If you have other examples of Windows tools which display similar aberrant behavior we can add those as well.I don't agree that the new behavior "breaks the stop-parsing symbol" at all, we're constructing the argument list appropriately which is why I'm marking this
by-design.Add find to legacy behavior for Windows.
rmccampbell commentedon Jul 20, 2022
Ignoring the oddities of find.exe, I think the --% syntax is still broken. By my understanding it should bypass both powershell parsing and any escaping, and pass the rest of the command line directly to the app, the same as it did in Legacy mode. This isn't the case though:
The Standard mode should match the Legacy mode here IMO.
(I'm not sure what the behavior should be if there are arguments before the --%, preferably those arguments would be properly escaped but I think that's probably irrelevant in most cases)
rmccampbell commentedon Jul 21, 2022
Is this actually by design, given my previous comment? It doesn't seem to be usefully designed if so. That means that probably many cases would have to use
cmd /cto get exact control over the command linemklement0 commentedon Nov 25, 2022
Ryan McCampbell (@rmccampbell) , please see