Add "ConsoleBouncer" option, to terminate stragglers (to fix ctrl+c)

Description of the new feature/enhancement

Ctrl+c cancellation does not work really well on Windows. Each process attached to a console receives a ctrl+c signal (as opposed to just the active shell), and sometimes, when a shell has launched some large tree of child processes (imagine a build system, for example), some processes do not exit (perhaps due to races between process creation and console attachment), leaving multiple processes all concurrently trying to consume console input, which Does Not Work Well™. It’s usually not too bad when cmd.exe is your shell, because you can just keep mashing on <kbd>ctrl</kbd>+<kbd>c</kbd> and usually get back to a usable state. But it’s considerably worse in PowerShell, because PSReadLine temporarily disables ctrl+c signals when waiting at the prompt, which can lead to the console being completely unrecoverable.

In the ConsoleBouncer project, I sought to solve the problem with a PowerShell module. When loaded, the module installs a ctrl+c handler, and takes inventory of processes currently attached to the console; these are the “allowed processes”. When a ctrl+c signal is received, all processes not in the “allowed list” (if any) are terminated.

This approach has some weaknesses. For one, it assumes that <kbd>ctrl</kbd>+<kbd>c</kbd> means “kill everything and get back to the shell”, but that assumption is not always true. The Windows console debugger processes kd.exe and cdb.exe, for example, handle <kbd>ctrl</kbd>+<kbd>c</kbd> (interpreting it as a signal to break into the target). So ConsoleBouncer is perhaps mostly-good-enough for most people who need it, probably, but is definitely too kludgy for “everyone”. But PSReadLine could implement something similar that would actually solve the problem more directly.

The defining characteristic of a borked shell is that in its mind, it is just sitting at the prompt, waiting for user input, where at the same time, there are other processes attached to the console, also consuming input (leading to wild and unpredictable behavior, as different keystrokes go to different processes). The ConsoleBouncer module works by receiving a ctrl+c signal, and it does not know what PSReadLine in the shell (or anybody else) is up to. It assumes that ctrl+c means “everybody out!” (And it’s that assumption that is “mostly good enough”, but not really completely true.)

But if the solution were baked into PSReadLine (as an off-by-default option), it could be done differently: instead of triggering the “clear out the riff-raff” behavior upon receipt of a ctrl+c signal, it should only kick out loiterers right before displaying the next prompt. I.e. when it believes it is ready to just sit around and wait for user input (right before it calls SetConsoleMode to disable ctrl+c), it could just take steps to make sure that that user input is going to be able to come to it (whack the non-allowed PIDs).

Proposed technical implementation details

Add a new option (off by default), named “???” (TerminateStragglers?). When enabled, PSReadLine will capture the list of processes currently attached to the console (via GetConsoleProcessList). Before displaying the prompt, it will check the attached processes again, and terminate any that are not in the list of allowed processes.

[jazzdelightsme]

@StevenBucher98 @daxian-dbw already done! 😄

[jazzdelightsme]

It will be a switch parameter on the Set-PSReadLineOption cmdlet. Since it’s off by default, I don’t think there’s a need for an experimental feature to gate it.

Yes, “stragglers” are processes… but I’m not sure if just adding “processes” into the name really makes things much clearer. “Stragglers” in this context are non-GUI, console-attached grandchildren processes; or put another way, non-GUI grandchild processes that are still attached to the console when it’s time for the shell to start reading input again (back at the prompt). I think “TerminateOrphanedConsoleApps” captures that pretty well… thanks, @sdwheeler!