interactive win32 console programs are broken (input and output) about cbwin HOT 5 CLOSED

The general idea would be to:

• save initial console modes at startup
• just before a win32 process is started or resumed, save then restore applicable console modes (might be none if everything is redirected) to initial ones (or profit from an already existing restoration, in which case reference count it)
• just after a win32 process is stopped or suspended, and if no other win32 processes using such applicable console modes restored to initial ones, restore applicable console modes again to WSL ones.

We will default to support interactive win32 programs, and maybe add a flag to keep stdin alone (for batch works). IMO this choice is better than adding a flag for interactive usage just to keep Ctrl-Z working by default on e.g. builds. However, if this really breaks Ctrl-Z, some people who might have taken the habit of Ctrl-Z'ing GUI programs, then bg them (because they use to do that under a GNU/Linux system) might be irritated by such breakage. That's one more argument if favor of detection of Win32 GUI programs.

from cbwin.

commit ab86dc8

Unfortunately this does not fix all the issues in the AU edition (maybe because of issues in WSL/Console implementation?), but it works quite well in the last Insider build 14946

The wcmd echo. workaround also is not needed anymore.

from cbwin.

However, Ctrl-C while running e.g. wcmd dir /s c:\\ now kills the whole console. I will try to avoid that...

from cbwin.

I think there are several steps needed to handle Ctrl-C "properly":

1. setup a handler in outbash (we cannot just ignore it, because that would be inherited by all children processes)
2. start bash.exe in a way that makes it ignore Ctrl-C
3. launch wanted programs in another way to keep Ctrl-C effective for them

from cbwin.

ctrl-c fixed by 771616d
closing this ticket to document remaining issues more clearly

from cbwin.