Repository navigation
Add testexe.exe -echocmdline to output raw command line received by the process on Windows - #18591
Conversation
testexe.exe -echoargs to output raw command line received by the process on Windowstestexe.exe -echoraw to output raw command line received by the process on Windows
Steve Lee (SteveL-MSFT)
left a comment
There was a problem hiding this comment.
I know you're adding this as part of researching some issues with $PSNativeCommandArgumentPassing, but would it makes sense to add some pester tets for native command arg passing using this test feature?
I updated the changes to make What pester tests you'd like to add using |
testexe.exe -echoraw to output raw command line received by the process on Windowstestexe.exe -echocmdline to output raw command line received by the process on Windows
| rawCmdLine = Marshal.PtrToStringUni(cmdLinePtr); | ||
| } | ||
|
|
||
| Console.WriteLine(rawCmdLine); |
There was a problem hiding this comment.
Would it make more sense to return a non-zero exit code and write message to StdErr?
There was a problem hiding this comment.
return a non-zero exit code and write message to StdErr
What is the purpose of doing this? Do you have some testing scenarios in mind that would need it?
There was a problem hiding this comment.
It is what any well-behaved CLI should do: print error messages to stderr, indicate failure via a non-zero exit code. Except in cases where backward compatibility must (unfortunately) be maintained, there's no good reason not to do this.
There was a problem hiding this comment.
I agree with Michael Klement (@mklement0), even though this is a test tool, we want to set good examples as other folks may end up using this code for their own projects.
There was a problem hiding this comment.
I'm afraid I need some clarification on this.
Are you suggesting returning non-zero exit code and write an error message instead of just writing out N/A when running on non-windows? The initial comment looks like suggesting always doing that.
There was a problem hiding this comment.
If I understood Steve Lee (@SteveL-MSFT) correctly, his comment was solely related to this unrelated piece of code, which deals with passing an unknown test name to the utility (the cited code originally showed that).
default:
Console.WriteLine("Unknown test {0}. Run with '-h' for help.", args[0]);
break;There was a problem hiding this comment.
Steve Lee (@SteveL-MSFT) Is that what you mean?
There was a problem hiding this comment.
I have updated that piece of code based on the feedback. Please let me know if you mean something else.
|
Maybe James Truher (@JamesWTruher) has some ideas on what tests can use this. Just seems odd to have this in testexe without it being used in a test. That can be a separate PR and doesn't block this PR as this is useful for investigating issues. |
|
This PR has Quantification details
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a
What can I do to optimize my changes
How to interpret the change counts in git diff output
Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email) |
|
Steve Lee (@SteveL-MSFT) Can you please take another look when you get a chance? Thanks! |
|
🎉 Handy links: |
… the process on Windows (PowerShell#18591)
PR Summary
Add
testexe.exe -echocmdlineto output raw command line received by the process on WindowsIt could be useful to print out the raw command line received by the testing process on Windows because it will show what is actually passed in by PowerShell when starting a native command.
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.