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

[mklement0]

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.

[iSazonov]

I think we should improve that on Unix. We should consider to start new process in new process group too not only background process in the same process group.

[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.

[SteveL-MSFT]

@PowerShell/powershell-committee discussed this, we agree that most of the time, users don't need to use Start-Process, however, on Unix, it does have at least one applicable use case:

Start-Process can start a new process without inheriting the current environment

PS /home/steve> $env:foo = "bar"
PS /home/steve> start-process "powershell" -args '-c $env:foo'                                                                                 
PS /home/steve> bar

PS /home/steve> start-process "powershell" -args '-c $env:foo' -UseNewEnvironment

So we plan to leave it.

[mklement0]

@SteveL-MSFT:

Good point about -UseNewEnvironment, but note that its current implementation is virtually useless - see #4671

Also, your example only makes sense with -Wait (the only reason that you didn't see a problem is that your command happened to produce no output).

To summarize the use cases for Start-Process on Unix:

• Launch a blocking GUI-launching CLI such as gedit asynchronously, launch-and-forget-it style.

• Run a non-interactive CLI with a pristine environment with -UseNewEnvironment -Wait

  • As stated, an interactive CLI launched this way - such as new interactive pwsh instance - competes with the calling instance for control of keyboard input.

  • Because use of Start-Process makes the process run outside of PowerShell's streams (by default, the process' output would print straight to the terminal), the only way to provide input / collect output is via the -Redirect* parameters, which require auxiliary files.

• Launch a process with -PassThru and use .WaitForExit() with a timeout on the returned System.Diagnostics.Process instance in order wait for termination only for a given amount of time.

[mklement0]

I've created a doc issue: MicrosoftDocs/PowerShell-Docs#2690