Clarify the purpose / behavior of the Start-Process cmdlet on Unix platforms

On Windows, the default behavior of Start-Process is to run a program in a new window, asynchronously. Console applications can optionally be forced to run in the current console (terminal) with -NoNewWindow, but that is of limited usefulness.

On Unix (Linux and macOS), as of PowerShell Core v6.0.0-beta.5, -NoNewWindow is the implied and unchangeable default: terminal (console) programs invariably execute in the current terminal, which is rarely useful: A program asking for interactive input interferes with the current shell and/or one producing (non-redirected) output prints it asynchronously to the current terminal, which can be disruptive - see #1543.

For non-interactive terminal programs, launching a job, e.g., by simply appending & - is the superior alternative, given that it allows you to determine success and inspect the output later.

For synchronous invocations, using -Wait is also pointless on Unix:

• To run a terminal-based application synchronously, just invoke it directly - no need for Start-Process

• -Wait is not effective with a GUI-launching CLI such as code for Visual Studio Code, which launches the GUI asynchronously, but in a manner that Start-Process doesn’t detect.

This leaves just the following narrow use cases for Start-Process on Unix:

• Launching a terminal-based application asynchronously, assuming that that application doesn’t request interactive user input (something that is supported in Bash - see below) and ideally doesn’t produce (non-redirected) stdout/stderr output, as that would print asynchronously in the current terminal.
• Launching a GUI application whose CLI is blocking - e.g., gedit - in a non-blocking manner: Start-Process gedit, as a light-weight, launch-it-and-forget-it alternative to gedit & (which invariably creates a job).

---

Is the current Start-Process behavior what is intended for the v6 release on Unix?

If so:

• The documentation should clearly state its limitations.
• Perhaps runtime warnings for pointless invocations can be implemented.

As an aside: On Windows, Start-Process can also open documents, whereas on Unix only Invoke-Item can do that.

[mklement0]

@iSazonov:

I fear that that is not enough, because we would then need Bash-like job-control features, such as bringing a background job back to the foreground in case it needs interactive input (and “stopping” (suspending) it first if that happens in the background, and being able to send it back to the background.

Using PS jobs behind the scenes is not an option, because, as far as I know, there’s no support for jobs requesting interactive (non-redirected stdin) input.

Also, PS jobs don’t output directly to the invoking terminal the way Bash jobs do by default.

P.S.: I’ve updated the initial post to point out that Start-Process -Wait too is pointless on Unix.

[mklement0]

I’ve created a doc issue: https://github.com/PowerShell/PowerShell-Docs/issues/2690