GeezerVison

Is it needed? What does create this file?

I'm not sure, but it was showing up at least on my Linux box.

Perhaps, we should do a wild-card, like *.nuget.props

Sorry for hustle, I know that I suggested this name run yesterday. I didn't find a good one at the moment, but now I think we should use bin instead of run, because it would match dotnet output.

Should Contain usage here makes it's harder to troubleshoot the error. When it accured.
Here, I'm trying to execute the test on the inbox powershell v5.1

Describing Native Command Arguments
 [+] Should handle quoted spaces correctly 619ms
 [-] Should handle spaces between escaped quotes 127ms
   Expected: file TestDrive:\test.txt to contain {Arg 0 is <a"b c"d>}
   19:         $testPath | Should Contain 'Arg 0 is <a"b c"d>'
   at <ScriptBlock>, F:\dev\PowerShell\test\powershell\Scripting\NativeExecution\NativeCommandArguments.Tests.ps1: line 19

As you see, I don't have information about the produced outpuit immediately in my disposal.
Just to find what we are currently produce I would need to run commands by hands.

I suggest to replace $testPath | Should Contain 'Arg 0 is <ab cd>' by

$lines = Get-Contetxt $testPath
($lines | measure).Count | Should Be 3  # this line will help get a better error message in case there is only one line in the output
$lines[0] | Should Be 'Arg 0 is <ab cd>'

Why bother writing the file? You can just capture the output in a variable with:

$lines = & $echoArgs $a 'a"b c"d' a"b c"d

I was trying to do what I thought would be reasonable, but it didn't seem to work with Pester:

& $echoArgs $a 'a"b c"d' a"b c"d | Should Match @"
Arg 0 is <ab cd>
Arg 1 is <ab cd>
Arg 2 is <ab cd>
"@

It seems like Pester only tries to match the first line of output when using Should Match. 😕

It's because powershell take output line by line.
You can add | Out-String | to get a single string.
Mulit-line probably indeed appropriate here, but I'd like to bring up couple things:

• please, use Be, not Match, because Match takes regex.
• Multi-line output will likely cause problems on cross-platforms, because of line-endings.

I suggest use what I described above, with array of 3 strings. It avoids problems with line-ends and produce a reasonable good error message.

I'd like to understand this better.

"a\`"b c\`"d"

There is a mix of two things:
backticks as powershell string escape mechanics and \ as command line args escape mechanics

This is an equivalent of 'a\"b c\"d'
When I use ehcoargs from cmd:

EchoArgs.exe a\"b c\"d

I'm getting

Arg 0 is <a"b>
Arg 1 is <c"d>

So the behavior that is currently described with Arg 1 doesn't seem right.

That's because it should be sent to EchoArgs as EchoArgs.exe "a\"b c\"d" with the outer quotes.

I see. I'd like to dig this a little bit more on all platforms, just to make sure we are doing the right thing.
At the meantime, can I ask you to add comments in the tests, so it's easier to maintain them?
Particularly the line

"a\`"b c\`"d"

already requires knowledge about both PS and native args passing escaping.

Will come back to this today after some experiments.
Thank you, again, for such thoughtful approach to the PR!