CTRL + C isn't being passed to certain applications (but the default WSL terminal works)

[nickjj]

For reference I am using wsltty 3.0.0 on the latest stable version of Win 10 Pro 18.09.

When you install Docker for Windows you get docker.exe and docker-compose.exe executable files that you can run. In the past this was all sorts of broken to access through WSL but some progress has been made recently and I wanted to check it out.

However, with wsltty, if you do docker-compose.exe up on a project that has containers running in the foreground, pressing CTRL + C has no effect. It's like the signal gets completely absorbed by wsltty.

But if I do the same thing with the default ubuntu.exe terminal provided by WSL, it works there.

You can reproduce this if you install Docker for Windows and follow the instructions below:

I have an open source Docker project that you can use to test this on.

git clone https://github.com/nickjj/build-a-saas-app-with-flask
cd build-a-saas-app-with-flask
cp .env.example .env
docker-compose.exe up

After about a minute (it needs to download some official Docker images and build the project) it will launch a few containers running in the foreground.

Pressing CTRL + C has no effect. It seems wsltty intercepts and throws away the signal.

If I do the same workflow with the default WSL terminal, CTRL + C correctly stops the containers.

[nickjj]

This issue occurs when launching wsltty (the application installed from this repo), which has a target of C:\Users\Nick\AppData\Local\wsltty\bin\mintty.exe --WSL="Ubuntu-18.04" --configdir="C:\Users\Nick\AppData\Roaming\wsltty" -~.

If I run wslbridge.exe which I did by doing:

• Win + S and open cmd.exe
• cd %LOCALAPPDATA%\wsltty\bin
• wslbridge.exe

Then the command prompt spams a bunch of \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ characters. Then I navigate to my source directory and run docker-compose.exe up which produces no output at all and hangs forever, ignoring CTRL + C.

In the mintty binary case, it at least produced the correct output when the program was running in the foreground but also ignored CTRL + C just like wslbridge.

[mintty]

Duplicate of #41.

[nickjj]

Are you sure it's a duplicate? Docker Compose doesn't mention any warnings or errors. It just refuses to accept CTRL + C as input while it runs successfully in the foreground.

Where as the default ubuntu.exe terminal runs correctly.

[mintty]

Well, at least it will have the same root cause, the interoperability problems between Windows console and Cygwin pty (mintty/mintty#56), aggravated by the callback situation when invoking Windows apps from WSL which is invoked from a Cygwin terminal. A workaround using the new Windows ConPTY API is anticipated in cygwin (cf. mintty/mintty#804), however, it's unclear whether that will also fix the reverse scenario.

[nickjj]

Will that mean it will work in wsltty eventually if the workaround works? If so, is that in the short or long term future? I do see that some of those issues have been open for a while.

How does Microsoft get around the problem with their default WSL terminal?

[mintty]

Their "terminal" is based on the traditional "conhost" console, serving the Windows console API.
It does not use a pipe-style pty interface as basically all other terminals do.

[nickjj]

What does that mean in the end for end users of wsltty? Will running Windows apps in the foreground not be possible inside of WSL with this terminal?

The Docker use case is pretty big IMO.

[mintty]

The Docker case has been discussed in the issue I referred to. A possible solution approach has been outlined there. Otherwise, I'm curious what the ConPTY patch will do, but I'm not a fortuneteller.

[nickjj]

Those are separate issues it seems.

That issue is all about the input device is not a TTY. If you are using mintty, try prefixing the command with winpt. But this issue isn't about that. I do not get that warning.

The things discussed there are also over a year old and it's hard to track what is what. Why do you need to be a fortuneteller? Have no patches been released since then?

Remember, your end users aren't terminal developers. I just run wsltty and it opens a terminal. I don't really know what conpty is or what the difference between mintty and conhost is. My simple mind just sees "the default WSL terminal works, wsltty does not, so let me report a bug to help the developers".

Is this something you can't fix with wsltty? What is the bottleneck?

[mintty]

From a plain user point of view: a workaround for the cygwin framework is under construction and may go into the next cygwin release. Or the one after it. And it may fix the described issue. Or not.

[nickjj]

Ah, I never installed cygwin. I didn't think it was being used in WSL, or was even a thing at the terminal level.

You should just join the MS team and work on their terminal. Instead of having 2 good but buggy terminals in their own ways. Make 1 really good terminal!

[mintty]

https://github.com/mintty/wsltty/#components-and-credits
Cygwin is an implicit part of wsltty. And so is mintty which is the cygwin terminal. wsltty is only an additional use case for it. And it's the MS interoperability that's buggy, not the terminal.

[mintty]

Released 3.1.0.2, bundling binary installer with cygwin 3.1.0, with ConPTY support.
Please recheck.

[nickjj]

Using 3.1.0.2 has no effect on the issue. It still doesn't respond with CTRL + C using the same work flow defined in the original post. You should re-open the issue because it's not fixed.

[Chronial]

Easier way to reproduce this issue is to run ping.exe 127.0.0.1 and try to kill it with CTRL + C.

[Chronial]

This is now suddenly working for me. wsltty 3.1.0.2 Windows version 1909 build 18363.535

[nickjj]

@Chronial is 19.09 an insider release?

[Chronial]

No, that's just the latest version: https://docs.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-1909

[mintty]

According to one comment above, this issue has resolved into void; can we close it?

[Chronial]

Sry, I must have missed your previous comment. I agree that this issue can be closed.