Proposed command `Invoke-Process` - to solve common problems with Start-Process -Wait and stream redirection about powershell HOT 7 OPEN

I will say once you start getting into a C# cmdlet you need to manually put in wait / halt points by overriding StopProcessing and having something checking for Ctrl+C when you're doing waiting like this, which will complicate the code somewhat. It's very doable, though; you can refer to the Start-Sleep command for some clues on how that works for a cmdlet.

Also, iirc $process.WaitForExit() is not always fully reliable and there are other ways to check for a process stopping -- I think hooking into its Exiting event is one of the more reliable ones?

I think it's also worth noting that if you're doing redirection like this you can't use -Verb RunAs (or set UseShellExecute = true), as that breaks the redirection.

So I would encourage you to take a look at actually building a cmdlet to see the full scope of how it needs to work and tie in, and also the problems you're going to run into (e.g., is there a different way to handle redirection while starting a process as admin? I vaguely recall you might be able to do something interesting with named pipes, but I've no idea how that works in practice;; does Ctrl+C correctly cancel the command and the running process?).

Also, I'm not clear here why this wouldn't just be an enhancement to Start-Process, ultimately. Possibly if the behaviour is different enough you could put it behind a switch to enable certain parts of it, but I'm not sure even that's warranted.

from powershell.

Also, I'm not clear here why this wouldn't just be an enhancement to Start-Process, ultimately

To me the difference would how Start-Process starts and optionally outputs the process object whereas running an inline process runs and outputs the stdout/stderr. Trying to overload Start-Process with more parameters to retrieve the output doesn't make too much sense from a UX perspective because as you've said things like -Verb just doesn't really apply.

What I would love to see is basically what a normal exe invocation does in PowerShell but exposed as a cmdlet. This cmdlet would then provide the normal behaviour but also allow you to:

• Change stdio encoding without resorting to [Console]::OutputEncoding and the rest
• Choose how stderr is handled
• $LASTEXITCODE checking as a switch
• Provide a command line string (Windows only) or an array of args
• Provide a way to choose how that array is escaped
• Custom credentials
• Potentially pty output

Basically it's the normal invocation but a more pwsh friendly way of controlling how that works which doesn't involve either global settings or vars that people don't really know about.

I agree that this should be a C# cmdlet, there are too many problems when it comes to events, stopping, etc that makes this unviable as a script function.

from powershell.

hi, interesting idea. I would second the idea of making it C#. A couple of further observations

• don't do anything like with verbs etc. Make it also work on Linux.
• reading until end of file on both the child process stdout and stderr should be sufficient to know the process has ended, then do the wait for the process to exit as you have it, I suggest hooking into events is less reliable
• not all processes write text to stdout, the output may be binary (eg gzip etc).
• rather than Ctril+C handling, I suggest using StopProcessing and send a signal to the child process or close stdin
• shouldn't you also handle stdin by passing ValueFromPipeline or similar to the stdin of the process?
• you may not need to use ThreadJob, you could use standard C# threads and accumulate the output in either a StingBuilder or MemoryStream.
• I suggest either support non-zero exits either through Write-Error or LastExitCode, not both mechanisms.
• what happens if you launch a non-console process?
• make sure all stdin, stdout and stderr streams are properly closed to avoid handle leaking
• You could pass the content from stderr to a scriptblock via steppable pipeline so the module does not have to make the decision on whether it should go to information or error streams.

I see no problem with this being a PSGallery module rather than having to be in PowerShell itself, then it can be used on any version of PowerShell.

from powershell.

I see no problem with this being a PSGallery module rather than having to be in PowerShell itself, then it can be used on any version of PowerShell.

Agree, there's nothing proposed that doesn't allow this cmdlet to be in a separate module published to PSGallery. If there is sufficient feedback and usage, we can decide separately whether it NEEDS to be part of PS7.

from powershell.

Thanks everyone for the great feedback and ideas! Publishing this as a separate module to the PSGallery seems like a great way to make it available quickly, gather early feedback on the cmdlet, and how useful it might be more broadly.

I considered doing this before posting this proposal, but didn't want to step on the built in *-Process commands or any plans this group might have already had to improve the use cases this serves. Internally I've published this to our feeds as the 'Process' module, but this is already on the PSGallery. Any suggestions for good alternative names?

If we go this route I'd want to make it an OSS project. I can do that under the Microsoft org (I'm a Microsoft FTE), but perhaps I could work with someone on this group to add the module to the official PowerShell org? Is owning this module long term something the PowerShell org would be willing to take over? Would be great to have more folks/organizational power behind it than just me in my corner. :)

Does anyone see problems with going this route?

Thanks again for the responsive and thoughtful feedback!

from powershell.

@jwittner I would suggest just having a repo under your GitHub account for now. Depending on the popularity/feedback, we can find a more formal home for it later. Thanks for taking this up!

from powershell.

See also:

• #18991

from powershell.