Ctrl+D (EOF) input doesn't close a WSL terminal

[armak]

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.356]
Windows Terminal version: v0.8.10091.0

I'm using the zsh shell.
The "closeOnExit" setting set to `true`, but the behavior is the same regardless.

Steps to reproduce

1. Open Windows Terminal
2. Run a command or execute a program that exits with a code other than 0
3. Press Ctrl+D

Expected behavior

Terminal window (or tab) is closed as if the exit command was given.

Actual behavior

Terminal prints a new line and then [process exited with code 127] (the number being the previous command's exit code), and finally an input prompt on the same line, but no text input is accepted. Terminal session is halted and doesn't accept input (surrounding UI and new tabs do work).

I believe this behavior is new in the 0.8... version and didn't exist in the previous official preview release. Running the same WSL environment via cmd.exe also behaves as expected, immediately closing the command line after entering the EOF code.

Also in other exit code cases (such as giving Ctrl+D directly to a fresh terminal), Windows Terminal exits as expected.

Visual example:

[ffes]

This is the new implementation of closeOnExit. Read all about in the release notes. The problem you describe annoyed me as well. I added a global setting (see the release notes how to update your config file) and set closeOnExit to always.

"defaults": {
    "closeOnExit": "always"
},

Another problem is that it is not possible to close the tab with the keyboard when the error you describe occurs, at least I couldn't find any. But maybe that needs a separate issue.

[DHowett-MSFT]

not possible

We haven’t had any trouble with Ctrl+Shift+W after the connection closes unexpectedly.

We are still evaluating to see whether this (^D causing abnormal termination of the shell) is expected for Linux shells or not. Even if it’s not expected, this will be a wsl issue instead of a Terminal issue. If it is expected, this’ll just have to be by-design.

[DHowett-MSFT]

Alright! This one is just by design. Sorry.

% zsh -l; echo "shell exited with code $?"
% ^D
shell exited with code 0

% zsh -l; echo "shell exited with code $?"
% false
% ^D
shell exited with code 1

% bash -l; echo "shell exited with code $?"
$ ^D
shell exited with code 0

% bash -l; echo "shell exited with code $?"
$ false
$ ^D
shell exited with code 1

It looks like a shell terminated with ^D propagates out the exit code of the last thing that happened:

% bash -l; echo "shell exited with code $?"
$ ( exit 100 )
$ ^D
shell exited with code 100

Terminal (and any other terminal emulator that supports this, like iTerm2 on macOS or ConEmu or ...) has no way of knowing that the "failed" exit code was, in fact, one propagated out of the process on somebody else's behalf.

[DHowett-MSFT]

As far as workaround: closeOnExit -> always is very good for shells you know and trust, but we can't set it by default on all WSL instances because then we'd fail to catch any unexpected failures ("distro doesn't exist", "wsl subsystem is down", etc.) and the user's terminal would immediately flicker open and close.

[DHowett-MSFT]

And as a final note, the test above was performed on actual Linux. 😀

[armak]

Thanks, the "always" option seems to yield the expected result always. Also, running the same test as above on a native Ubuntu 18.04 yields the same result as well, the terminal is immediately closed on Ctrl+D.

[DHowett-MSFT]

The native Ubuntu terminal does not do process exit code detection by default. Because of this, if your shell is misconfigured it will open, print out a heap of text, and then close without letting you see it.

It looks like it's configurable. If you set this...

to Hold the terminal open, you get this -- even if you use ^D

(I did use ^D, but bash prints exit or logout when you do that.)

We chose to hold the terminal open by default as we think it's a better experience.

[ffes]

not possible

We haven’t had any trouble with Ctrl+Shift+W after the connection closes unexpectedly.

My bad, sorry for that noise 😕