Powershell: capture Command-Line tool stream(stdout, stderr) into powershell

[tlsalex]

Summary of the new feature/enhancement

When using start-process to start a process like ping nslookup , the stream of stdout, stderr is not comming into powershell relative stream.

Start-Process cmd -ArgumentList "/c c:\software\test.bat"

the test.bat only contains ipconfig

however it returns nothing within powershell

if do that like this
$getip= Start-Process cmd -ArgumentList "/c c:\software\test.bat" 2>&1
$getip is still an empty variable.

So I hope powershell can capture those cmd-tools' stream into its own stream.

PS: I know we can run cmd tool directly within powershell, just for illustration.

Proposed technical implementation details (optional)

[doctordns]

From PowerShell, there is no need to run cmd.exe to, in turn, run another command such as nslookup.exe or ipconfig.exe.

Just run it natively:

ipconfig /all

[vexx32]

Also, if you do want to use Start-Process, you can use -NoNewWindow to make the stdout/stderr capturable.

[SeeminglyScience]

@doctordns

From PowerShell, there is no need to run cmd.exe to, in turn, run another command such as nslookup.exe or ipconfig.exe. (...) Just run it natively:

FYI they do mention that in the issue and that the example given is just for demonstration purposes.

@vexx32

Also, if you do want to use Start-Process, you can use -NoNewWindow to make the stdout/stderr capturable.

Not capturable, it just writes directly to stdin/out.

---

I've often wanted something like this for when native commands have conflicting syntax but I also need to pass a variable (making the stop parsing operator not usable). It would be nice if there was a way to manually craft an argument list but still allow stdin/out to work like it does with the native command processor.

[vexx32]

Good point. You can get creative with defining your arguments:

$process = 'pwsh.exe'
$args = @(
     @'
-ExecutionPolicy Bypass
'@
    '-File'
    'C:\Scripts\script.ps1'
)

& $process @args

I'm sure it doesn't solve everything but it does make some complex situations much simpler.

[SeeminglyScience]

Give that a go and you'll see part of the problem 😉

[vexx32]

Yeah it's a mess of trial end error, but it's usually more doable than some of the alternatives. Could be better, always.

[SeeminglyScience]

Yeah for sure, same can be said about just normal inline syntax though. If this feature was added it would be a great last resort catch all. Right now if I run into an executable like that I either have to drop all stdin/out and work off just exit code or hack together my own implementation that uses Process directly and reads redirected output/error.