starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

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

New Issue
Closed
opened 2026-01-31 00:25:13 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 00:25:13 +00:00
Owner
Copy Link

Originally created by @armak on GitHub (Jan 14, 2020).

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:
image

Originally created by @armak on GitHub (Jan 14, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none 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: ![image](https://user-images.githubusercontent.com/4991927/72391731-ae48f500-3736-11ea-861f-977d1a881b9e.png)
claunia added the Resolution-By-DesignNeeds-TriageNeeds-Tag-Fix labels 2026-01-31 00:25:13 +00:00
claunia commented 2026-01-31 00:25:15 +00:00
Author
Owner
Copy Link

@ffes commented on GitHub (Jan 15, 2020):

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.

@ffes commented on GitHub (Jan 15, 2020): 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`. ```json "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.
claunia commented 2026-01-31 00:25:15 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

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 commented on GitHub (Jan 15, 2020): > not possible We haven’t had any trouble with <kbd>Ctrl+Shift+W</kbd> 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.
claunia commented 2026-01-31 00:25:16 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

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 commented on GitHub (Jan 15, 2020): 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.
claunia commented 2026-01-31 00:25:16 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

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 commented on GitHub (Jan 15, 2020): 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.
claunia commented 2026-01-31 00:25:17 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

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

@DHowett-MSFT commented on GitHub (Jan 15, 2020): And as a final note, the test above was performed on actual Linux. 😀
claunia commented 2026-01-31 00:25:17 +00:00
Author
Owner
Copy Link

@armak commented on GitHub (Jan 15, 2020):

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.

@armak commented on GitHub (Jan 15, 2020): 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.
claunia commented 2026-01-31 00:25:18 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 15, 2020):

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...

image

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

image

(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.

@DHowett-MSFT commented on GitHub (Jan 15, 2020): 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... ![image](https://user-images.githubusercontent.com/14316954/72467224-57bbd500-378f-11ea-84ef-24d76c7616b9.png) to _Hold the terminal open_, you get this -- even if you use `^D` ![image](https://user-images.githubusercontent.com/14316954/72467276-715d1c80-378f-11ea-81f0-7128919a3194.png) (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.
claunia commented 2026-01-31 00:25:18 +00:00
Author
Owner
Copy Link

@ffes commented on GitHub (Jan 16, 2020):

not possible

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

My bad, sorry for that noise 😕

@ffes commented on GitHub (Jan 16, 2020): >> not possible > > We haven’t had any trouble with `Ctrl+Shift+W` after the connection closes unexpectedly. My bad, sorry for that noise 😕
claunia commented 2026-01-31 00:25:18 +00:00
Author
Owner
Copy Link

@a-gn commented on GitHub (Feb 25, 2020):

@DHowett-MSFT Would it be possible to add an explanation message when this happens? It's the default behavior on WSL and it's quite confusing to see a tab stay open with an error. I couldn't figure whether something was wrong with WSL, bash, or the terminal app.

@a-gn commented on GitHub (Feb 25, 2020): @DHowett-MSFT Would it be possible to add an explanation message when this happens? It's the default behavior on WSL and it's quite confusing to see a tab stay open with an error. I couldn't figure whether something was wrong with WSL, bash, or the terminal app.
claunia commented 2026-01-31 00:25:19 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 25, 2020):

If we could detect that there was an exit code caused by the user pressing Ctrl+D, we would have circumvented the message entirely and closed the window 😄

@DHowett-MSFT commented on GitHub (Feb 25, 2020): If we could detect that there was an exit code _caused by the user pressing <kbd>Ctrl+D</kbd>_, we would have circumvented the message entirely and closed the window :smile:
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Tag-Fix Needs-Triage Resolution-By-Design
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5913
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?