Powershell: Not able to type properly in Console started using `Start-Process with -NoNewWindow`

[kvprasoon]

Steps to reproduce

Start-Process cmd -NoNewWindow

or

Start-Process pwsh -NoNewWindow

Then try writing something

Expected behavior

User should be able to type properly

Actual behavior

Behaves like having multiple prompts and input goes partially on each.

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0-preview.4
PSEdition                      Core
GitCommitId                    7.1.0-preview.4
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[SeeminglyScience]

Behaves like having multiple prompts and input goes partially on each.

That's exactly what's happening though. You'd need to add the -Wait parameter if you want the process to be invoked synchronously.

[DHowett]

Yeah, this is definitely by design. It’s like starting a background process that is vying for access to your single console window. You explicitly asked for that :smile: That’s never going to be a winning combination.

[kvprasoon]

@SeeminglyScience , @vexx32 Thinking from a normal user's perspective its very difficult to realize what is happening.

[vexx32]

I don't entirely disagree there, but short of a breaking change to reverse the behaviour (make -Wait the default and add a -NoWait switch to opt-in to this behaviour) there isn't a meaningful change that would improve things here.

Personally I think such a change is unlikely to be accepted simply because the current behaviour has (as far as I'm aware) been in place since the creation of the cmdlet, and suddenly inverting the behaviour has the potential to break pretty much any use of Start-Process.

Additionally, there are some other cases where making -Wait the default is completely undesirable, especially if you're invoking a GUI application. In many / most of those cases, having -Wait be the default would be more confusing instead of less, as the console would completely lock up until the application is closed.

[kvprasoon]

not really to make -wait default true, but some way to make the user not to face this, a warning/error would do the job I feel.

[vexx32]

I don't know that there is any way that PowerShell itself can actually detect this. @SeeminglyScience might have some ideas there if it's doable, but this sounds squarely like the kind of thing that could only be detected from the conhost end.

[DHowett]

Unfortunately, the decision as to whether conhost even gets launched happens somewhere inside kernel32 once the new process has already been started. There's nothing we can do to control the parent process's session once that happens--it's decision about how to spawn the child and whether to attach or detach it has already been made.

[SeeminglyScience]

The only thing Start-Process could try to do is check which subsystem the executable targets. If it targets the console subsystem, well even then that's not super helpful. It would have to know:

1. The executable targets the console subsystem
2. Whether it will try to read input
3. Whether the rest of the script after Start-Process will run longer than the started process
4. If the above is true, if any input is read in the rest of the script

I 100% get that it's confusing, I definitely hit the same thing at one point. Really though, it's doing pretty much exactly what it was asked to do.

[mklement0]

Updating the Start-Process help topic should help: see https://github.com/PowerShell/PowerShell/issues/1543#issuecomment-448453564 and https://github.com/MicrosoftDocs/PowerShell-Docs/issues/3013