[feature request] Add extra information for known error codes from WSL #16687

7734cd7d80/src/cascadia/TerminalConnection/ConptyConnection.cpp (L387-L397)

@zadjii-msft commented on GitHub (Feb 7, 2022):

This is where we print the error message:

This is somewhere similar in ConPTY connection where we print a specific message for a specific error,
7734cd7d80/src/cascadia/TerminalConnection/ConptyConnection.cpp (L369-L375)

https://stackoverflow.com/a/17387176/1481137 might be useful, but I don't think that works for HRESULTS

@zadjii-msft commented on GitHub (Feb 7, 2022): This is where we print the error message: https://github.com/microsoft/terminal/blob/7734cd7d80cd21d6237958b9437efe26c62231af/src/cascadia/TerminalConnection/ConptyConnection.cpp#L387-L397 This is somewhere similar in ConPTY connection where we print a specific message for a specific error, https://github.com/microsoft/terminal/blob/7734cd7d80cd21d6237958b9437efe26c62231af/src/cascadia/TerminalConnection/ConptyConnection.cpp#L369-L375 https://stackoverflow.com/a/17387176/1481137 might be useful, but I don't think that works for HRESULTS

claunia commented

@eryksun commented on GitHub (Feb 7, 2022):

STATUS_CONTROL_C_EXIT (0xC000013A, 3221225786) is an NTSTATUS code. The default console control handler exits with this status code, whether it's due to Ctrl+C, Ctrl+Break, or closing the console window/tab.

Usually if the exit status of a normal Windows process is an NTSTATUS code, it means the process either failed early during initialization or failed due to an unhandled OS exception such as STATUS_ACCESS_VIOLATION (0xC0000005), STATUS_STACK_OVERFLOW (0xC00000FD), or STATUS_STACK_BUFFER_OVERRUN (0xC0000409). The latter is also used by the __fastfail() intrinsic, with which the C runtime implements abort().

Functions that return HRESULT values can return the bitwise OR of an NTSTATUS code with FACILITY_NT_BIT (0x10000000). For example, return HRESULT_FROM_NT(STATUS_CONTROL_C_EXIT) or (HRESULT) (STATUS_CONTROL_C_EXIT | FACILITY_NT_BIT)

Error messages for most NTSTATUS codes are sourced from "ntdll.dll", after masking out FACILITY_NT_BIT of course. For example, in Python:

>>> flags = win32con.FORMAT_MESSAGE_FROM_HMODULE | win32con.FORMAT_MESSAGE_IGNORE_INSERTS
>>> hmod = win32api.GetModuleHandle('ntdll')
>>> langid = win32api.MAKELANGID(win32con.LANG_NEUTRAL, win32con.SUBLANG_DEFAULT)
>>> win32api.FormatMessage(flags, hmod, 0xC000013A, langid, None)
'{Application Exit by CTRL+C}\r\nThe application terminated as a result of a CTRL+C.\r\n'

There are some HRESULT values that mistakenly use the reserved "R" bit, which makes them look like NTSTATUS values, e.g. ERROR_AUDITING_DISABLED (0xC0090001). So if you're expecting an HRESULT and get what appears to be an NTSTATUS value, first try to handle it as a Windows (system) error code. For example:

>>> flags = win32con.FORMAT_MESSAGE_FROM_SYSTEM | win32con.FORMAT_MESSAGE_IGNORE_INSERTS
>>> win32api.FormatMessage(flags, 0, 0xC0090001, langid, None)
'The specified event is currently not being audited.\r\n'

@eryksun commented on GitHub (Feb 7, 2022): `STATUS_CONTROL_C_EXIT` (0xC000013A, 3221225786) is an [`NTSTATUS`](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/87fba13e-bf06-450e-83b1-9241dc81e781) code. The default console control handler exits with this status code, whether it's due to Ctrl+C, Ctrl+Break, or closing the console window/tab. Usually if the exit status of a normal Windows process is an `NTSTATUS` code, it means the process either failed early during initialization or failed due to an unhandled OS exception such as `STATUS_ACCESS_VIOLATION` (0xC0000005), `STATUS_STACK_OVERFLOW` (0xC00000FD), or `STATUS_STACK_BUFFER_OVERRUN` (0xC0000409). The latter is also used by the [`__fastfail()`](https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail?view=msvc-170) intrinsic, with which the C runtime implements `abort()`. Functions that return [`HRESULT`](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/0642cb2f-2075-4469-918c-4441e69c548a) values can return the bitwise OR of an `NTSTATUS` code with `FACILITY_NT_BIT` (0x10000000). For example, return `HRESULT_FROM_NT(STATUS_CONTROL_C_EXIT)` or `(HRESULT) (STATUS_CONTROL_C_EXIT | FACILITY_NT_BIT)` Error messages for most `NTSTATUS` codes are sourced from "ntdll.dll", after masking out `FACILITY_NT_BIT` of course. For example, in Python: ```python >>> flags = win32con.FORMAT_MESSAGE_FROM_HMODULE | win32con.FORMAT_MESSAGE_IGNORE_INSERTS >>> hmod = win32api.GetModuleHandle('ntdll') >>> langid = win32api.MAKELANGID(win32con.LANG_NEUTRAL, win32con.SUBLANG_DEFAULT) >>> win32api.FormatMessage(flags, hmod, 0xC000013A, langid, None) '{Application Exit by CTRL+C}\r\nThe application terminated as a result of a CTRL+C.\r\n' ``` There are some `HRESULT` values that mistakenly use the reserved "R" bit, which makes them look like `NTSTATUS` values, e.g. `ERROR_AUDITING_DISABLED` (0xC0090001). So if you're expecting an `HRESULT` and get what appears to be an `NTSTATUS` value, first try to handle it as a Windows (system) error code. For example: ```python >>> flags = win32con.FORMAT_MESSAGE_FROM_SYSTEM | win32con.FORMAT_MESSAGE_IGNORE_INSERTS >>> win32api.FormatMessage(flags, 0, 0xC0090001, langid, None) 'The specified event is currently not being audited.\r\n' ```

claunia commented

@vadimkantorov commented on GitHub (Feb 7, 2022):

For me. these WSL crashes happen sometimes during normal work, not at initialization without me hitting Ctrl+C. In any case, these crashes are likely linked to insufficient available RAM or to hard disk being too slow to respond / failing (especially during RAM paging process) - maybe the OS oom-kills the WSL process somehow. But in any case, extra textual info (+maybe a website link explaining more?) would be very helpful

@vadimkantorov commented on GitHub (Feb 7, 2022): For me. these WSL crashes happen sometimes during normal work, not at initialization without me hitting Ctrl+C. In any case, these crashes are likely linked to insufficient available RAM or to hard disk being too slow to respond / failing (especially during RAM paging process) - maybe the OS oom-kills the WSL process somehow. But in any case, extra textual info (+maybe a website link explaining more?) would be very helpful

claunia commented

@eryksun commented on GitHub (Feb 7, 2022):

The error message for the exit status code isn't likely to help, especially if it's just STATUS_CONTROL_C_EXIT (0xC000013A). For WSL, capturing an event log as shown on this page would likely provide useful diagnostic information.

@eryksun commented on GitHub (Feb 7, 2022): The error message for the exit status code isn't likely to help, especially if it's just `STATUS_CONTROL_C_EXIT` (0xC000013A). For WSL, capturing an event log as shown on [this page](https://github.com/Microsoft/WSL/blob/master/CONTRIBUTING.md#record-wsl-logs-manually) would likely provide useful diagnostic information.

claunia commented

@vadimkantorov commented on GitHub (Feb 7, 2022):

Hmm, my slow laptop also started to have keyboard failing. Now I get this WSL crash whenever I hit the key "b". I wonder if my keyboard somehow turned itself into the mode where it sends Ctrl+Break.

Indeed, the faulty key B now produces KeyboardEvent {isTrusted: true, key: '\x03', code: 'Pause', location: 0, ctrlKey: true, …}

@vadimkantorov commented on GitHub (Feb 7, 2022): Hmm, my slow laptop also started to have keyboard failing. Now I get this WSL crash whenever I hit the key "b". I wonder if my keyboard somehow turned itself into the mode where it sends Ctrl+Break. Indeed, the faulty key B now produces `KeyboardEvent {isTrusted: true, key: '\x03', code: 'Pause', location: 0, ctrlKey: true, …}`

claunia commented

@vadimkantorov commented on GitHub (Feb 7, 2022):

So maybe if Ctrl+Break is hit and this causes WSL process to terminate, should this lead to the tab being closed?

A similar case happens when one hits Ctrl+D to exit a terminal (this would be the outcome on Gnome Terminal), Terminal executes logout, but then the tab is not closed and instead [process exited with code 255] is printed on a cleared screen

@vadimkantorov commented on GitHub (Feb 7, 2022): So maybe if Ctrl+Break is hit and this causes WSL process to terminate, should this lead to the tab being closed? A similar case happens when one hits Ctrl+D to exit a terminal (this would be the outcome on Gnome Terminal), Terminal executes `logout`, but then the tab is not closed and instead `[process exited with code 255]` is printed on a cleared screen

claunia commented

@eryksun commented on GitHub (Feb 8, 2022):

So maybe if Ctrl+Break is hit and this causes WSL process to terminate, should this lead to the tab being closed?

You can configure the termination behavior in the settings for a profile or the default profile to one of the following options: close always; close on successful exit (0); or never close.

A similar case happens when one hits Ctrl+D to exit a terminal (this would be the outcome on Gnome Terminal), Terminal executes logout, but then the tab is not closed and instead [process exited with code 255] is printed on a cleared screen

The exit status for Ctrl+D should be 0, not 255.

In Unix, the closest to Windows Ctrl+Break is the terminal quit signal, which for me in Linux (not WSL) is Ctrl+\ (check stty -a). This sends SIGQUIT to the foreground process group. In Windows, Ctrl+Break sends CTRL_BREAK_EVENT to all processes in the console session. Shells such as CMD and PowerShell ignore the break event when waiting for a child process. When CMD is active in the foreground, Ctrl+Break cancels the current line, which is more to do with the console itself since the read gets canceled on the console side. For PowerShell in the foreground, Ctrl+Break enters a debugging mode.

I don't know why WSL doesn't map the break event to the pty quit signal instead of letting the default handler exit with STATUS_CONTROL_C_EXIT. But there's a lot I don't know about WSL.

@eryksun commented on GitHub (Feb 8, 2022): > So maybe if Ctrl+Break is hit and this causes WSL process to terminate, should this lead to the tab being closed? You can configure the termination behavior in the settings for a profile or the default profile to one of the following options: close always; close on successful exit (0); or never close. > A similar case happens when one hits Ctrl+D to exit a terminal (this would be the outcome on Gnome Terminal), Terminal executes `logout`, but then the tab is not closed and instead `[process exited with code 255]` is printed on a cleared screen The exit status for Ctrl+D should be 0, not 255. In Unix, the closest to Windows Ctrl+Break is the terminal quit signal, which for me in Linux (not WSL) is <kbd>Ctrl</kbd>+<kbd>\\</kbd> (check `stty -a`). This sends `SIGQUIT` to the foreground process group. In Windows, Ctrl+Break sends `CTRL_BREAK_EVENT` to all processes in the console session. Shells such as CMD and PowerShell ignore the break event when waiting for a child process. When CMD is active in the foreground, Ctrl+Break cancels the current line, which is more to do with the console itself since the read gets canceled on the console side. For PowerShell in the foreground, Ctrl+Break enters a debugging mode. I don't know why WSL doesn't map the break event to the pty quit signal instead of letting the default handler exit with `STATUS_CONTROL_C_EXIT`. But there's a lot I don't know about WSL.

claunia commented

@vadimkantorov commented on GitHub (Feb 8, 2022):

Most of time it's indeed 0, and Ctrl+D closes the tab automatically, but sometimes I evidence code 255, not sure why :/

@vadimkantorov commented on GitHub (Feb 8, 2022): Most of time it's indeed 0, and Ctrl+D closes the tab automatically, but sometimes I evidence code 255, not sure why :/

claunia commented

@vadimkantorov commented on GitHub (Feb 8, 2022):

I also got a nice one:

The I/O operation has been aborted because of either a thread exit or an application request.

[process exited with code 4294967295]

A tab was hung for a while, and during this time all other tabs were not responsive. Then I got this message and other tabs got unhung. It's as if Terminal performed some IO to WSL backend via a single thread that can be hung

@vadimkantorov commented on GitHub (Feb 8, 2022): I also got a nice one: ``` The I/O operation has been aborted because of either a thread exit or an application request. [process exited with code 4294967295] ``` A tab was hung for a while, and during this time all other tabs were not responsive. Then I got this message and other tabs got unhung. It's as if Terminal performed some IO to WSL backend via a single thread that can be hung

claunia commented

@vadimkantorov commented on GitHub (Feb 14, 2022):

Maybe also Terminal could print sth like "Press Ctrl + Shift + W to close this tab " for better keystroke discoverability

@vadimkantorov commented on GitHub (Feb 14, 2022): Maybe also Terminal could print sth like "Press Ctrl + Shift + W to close this tab " for better keystroke discoverability

claunia commented

@zadjii-msft commented on GitHub (Apr 7, 2022):

Hey look at that, we were already tracking this in /dup #7186. Thanks!

@zadjii-msft commented on GitHub (Apr 7, 2022): Hey look at that, we were already tracking this in /dup #7186. Thanks!

claunia commented

@ghost commented on GitHub (Apr 7, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Apr 7, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

claunia commented

@vadimkantorov commented on GitHub (Oct 18, 2022):

Currently, WSLv1 session just died at me with: [process exited with code 3221225786 (0xc000013a)]. Still no text description for HRESULTs / NTSTATUS / WinAPI error codes or whatever these are

@vadimkantorov commented on GitHub (Oct 18, 2022): Currently, WSLv1 session just died at me with: `[process exited with code 3221225786 (0xc000013a)]`. Still no text description for HRESULTs / NTSTATUS / WinAPI error codes or whatever these are

claunia commented

@zadjii commented on GitHub (Oct 18, 2022):

Yep, the issue that this was duped too is in fact, still open.

@zadjii commented on GitHub (Oct 18, 2022): Yep, the issue that this was duped too is in fact, still open.

claunia commented

@vadimkantorov commented on GitHub (Oct 18, 2022):

Also, may be clearer if that issue name is also expanded to reflect more than just errors on connection to conpty

@vadimkantorov commented on GitHub (Oct 18, 2022): Also, may be clearer if that issue name is also expanded to reflect more than just errors on connection to conpty

claunia commented

2026-01-31 05:19:45 +00:00

@vadimkantorov commented on GitHub (Nov 23, 2022):

When Terminal fails to connect to WSLv1 service, a new tab just times out and then prints an error code 1. It would be good if it showed a proper error message if it fails to connect to WSL (and maybe offers either to exit the tab on pressing a key or retrying to connect to WSL).

@vadimkantorov commented on GitHub (Nov 23, 2022): When Terminal fails to connect to WSLv1 service, a new tab just times out and then prints an error code 1. It would be good if it showed a proper error message if it fails to connect to WSL (and maybe offers either to exit the tab on pressing a key or retrying to connect to WSL). ![image](https://user-images.githubusercontent.com/1041752/203641155-f8b3f407-51ca-4185-b3ed-2e29c25c870a.png)

claunia commented

@zadjii-msft commented on GitHub (Nov 23, 2022):

@vadimkantorov That sounds like something that should be reported to https://github.com/microsoft/wsl. We can only surface the information given to us - and an error code of 1 is not terribly informative.

(and maybe offers either to exit the tab on pressing a key or retrying to connect to WSL).

That's in a PR that you've commented on 😉

@zadjii-msft commented on GitHub (Nov 23, 2022): @vadimkantorov That sounds like something that should be reported to https://github.com/microsoft/wsl. We can only surface the information given to us - and an error code of `1` is not terribly informative. > (and maybe offers either to exit the tab on pressing a key or retrying to connect to WSL). That's in a PR that [you've commented on](https://github.com/microsoft/terminal/pull/14060#issuecomment-1281857989) 😉

claunia commented

2026-01-31 05:19:45 +00:00

@vadimkantorov commented on GitHub (Nov 23, 2022):

Mainly I'm concerned here to have a good error message. I'm not understanding deep enough to understand what exactly is failing here and at what level, so I thought maybe it's some special tool that Terminal is invoking to create a WSL session.

If it's just calling wsl.exe, it might be worth it to solve crash / return code of wsl.exe at the Terminal level and have a generic "WSL session failed" at least. Of course a more specific message may be shown if WSL returns a more specific error code

@vadimkantorov commented on GitHub (Nov 23, 2022): Mainly I'm concerned here to have a good error message. I'm not understanding deep enough to understand what exactly is failing here and at what level, so I thought maybe it's some special tool that Terminal is invoking to create a WSL session. If it's just calling wsl.exe, it might be worth it to solve crash / return code of wsl.exe at the Terminal level and have a generic "WSL session failed" at least. Of course a more specific message may be shown if WSL returns a more specific error code

claunia commented

2026-01-31 05:19:45 +00:00

@vadimkantorov commented on GitHub (Dec 6, 2023):

@zadjii-msft

Btw, when typing exit in Command Prompt (running in Terminal), it currently does not exit the tab right away (I think it should!)

Instead it prints:

[process exited with code 9009 (0x00002331)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

9009 looks like some special error code, I think the Terminal should indeed close the tab if it receives a known exit code from cmd.exe like this - or at least print a better suited message. The current message is a bit too cryptic, for the very non-surprising tab's end of life

Interestingly, for WSLv1 tab, typing exit seems to produce first some similar message, but then the tab closes automatically without forcing to stroke Ctrl+D

When I typed exit the second time, the Terminal closed the tab, which makes me think that the existing tab auto-closing isn't very reliable

@vadimkantorov commented on GitHub (Dec 6, 2023): @zadjii-msft Btw, when typing `exit` in Command Prompt (running in Terminal), it currently does not exit the tab right away (I think it should!) Instead it prints: ``` [process exited with code 9009 (0x00002331)] You can now close this terminal with Ctrl+D, or press Enter to restart. ``` 9009 looks like some special error code, I think the Terminal should indeed close the tab if it receives a known exit code from cmd.exe like this - or at least print a better suited message. The current message is a bit too cryptic, for the very non-surprising tab's end of life Interestingly, for WSLv1 tab, typing `exit` seems to produce first some similar message, but then the tab closes automatically without forcing to stroke Ctrl+D When I typed `exit` the second time, the Terminal closed the tab, which makes me think that the existing tab auto-closing isn't very reliable <img width="518" alt="image" src="https://github.com/microsoft/terminal/assets/1041752/3647752b-6b41-46a4-9329-f3ce6c16bc3d">

claunia commented

2026-01-31 05:19:46 +00:00

@zadjii-msft commented on GitHub (Dec 6, 2023):

I mean, you could also just set closeOnExit: always.

9009 is MSG_DIR_BAD_COMMAND_OR_FILE, which is the error code for "'%1' is not recognized as an internal or external command, operable program or batch file"

You may also be seeing #16068. Not sure how far back we backported that.

@zadjii-msft commented on GitHub (Dec 6, 2023): I mean, you could also just set `closeOnExit: always`. `9009` is `MSG_DIR_BAD_COMMAND_OR_FILE`, which is the error code for "'%1' is not recognized as an internal or external command, operable program or batch file" You may also be seeing #16068. Not sure how far back we backported that.

claunia commented

2026-01-31 05:19:46 +00:00

@vadimkantorov commented on GitHub (Dec 6, 2023):

Well, what was strange that it did not work once, but then worked. So maybe this mechanism just is not 100% reliable

@vadimkantorov commented on GitHub (Dec 6, 2023): Well, what was strange that it did not work once, but then worked. So maybe this mechanism just is not 100% reliable

claunia commented

2026-01-31 05:19:46 +00:00

@vadimkantorov commented on GitHub (Dec 13, 2023):

Yeah, it happened again. Two times auto-closing did not work, but then worked again. And when it works, it first prints this error message [process exited with code 9009 (0x00002331)] You can now close this terminal with Ctrl+D, or press Enter to restart. and closes only after.

So it seems this autoclose is enabled by default but is certainly random/not reliable

@vadimkantorov commented on GitHub (Dec 13, 2023): Yeah, it happened again. Two times auto-closing did not work, but then worked again. And when it works, it first prints this error message `[process exited with code 9009 (0x00002331)] You can now close this terminal with Ctrl+D, or press Enter to restart.` and closes only after. So it seems this autoclose is enabled by default but is certainly random/not reliable

claunia commented

@DHowett commented on GitHub (Dec 13, 2023):

It's a lot less random than it seems!

Most shells project their last subprocess' exit code when they themselves exit. It also so happens that 9009 is the code CMD uses to indicate that a command was not found.

You can see this behavior consistently in cmd, bash and zsh, but not with PowerShell.

cmd

bash

zsh

pwsh

The "graceful" close-on-exit policy explicitly prefers keeping a tab open when it exits with an error. This includes expected errors like 9009 when you've just run a command that doesn't exist or pressed Ctrl+C in cmd.
If you don't like how the "graceful" close-on-exit policy works, you can always set it to "always" 😄

@DHowett commented on GitHub (Dec 13, 2023): It's a lot less random than it seems! Most shells project their last subprocess' exit code when they themselves exit. It also so happens that `9009` is the code CMD uses to indicate that a command was not found. You can see this behavior consistently in cmd, bash and zsh, but not with PowerShell. ### cmd ![image](https://github.com/microsoft/terminal/assets/189190/c5a3ec0e-177d-4c45-822a-87e10330f09d) ![image](https://github.com/microsoft/terminal/assets/189190/961407e1-193f-437e-b08c-0e4978c35fc5) ### bash ![image](https://github.com/microsoft/terminal/assets/189190/e2f571c5-0a85-40ef-8c55-0fc3eff4898b) ### zsh ![image](https://github.com/microsoft/terminal/assets/189190/047c46b5-7e3c-4215-b8fb-38c184d08865) ### pwsh ![image](https://github.com/microsoft/terminal/assets/189190/a9a89b20-4044-4826-b63f-1a842621ebc1) The "graceful" close-on-exit policy explicitly prefers keeping a tab open when it exits with an error. This includes expected errors like 9009 _when you've just run a command that doesn't exist or pressed <kbd>Ctrl+C</kbd> in cmd._ If you don't like how the "graceful" close-on-exit policy works, you can always set it to "always" :smile:

claunia commented

@vadimkantorov commented on GitHub (Dec 14, 2023):

I think che current behavior that terminal's tab should close-on-exit or not close-on-exit, depending in fact on behavior of previously run command is very unintuitive, especially as default behavior.

So I would propose to switch to "always" close-on-exit.

If this is absolutely not possible, I guess my a ask would be to add this information (+ some info on this close-on-exit and mode differences, reason of this show exit code and how to change it) to the printed message next to [process exited with code 9009 (0x00002331)] You can now close this terminal with Ctrl+D, or press Enter to restart., as typing some incorrect command (e.g. typing rm some_file_name in cmd.exe session by mistake instead of a WSL tab, then exiting it and starting a proper WSL tab) and then quitting with exit is fairly common.

in general, adding info on some known error codes of some standard Windows programs/utils would be nice

@vadimkantorov commented on GitHub (Dec 14, 2023): I think che current behavior that terminal's tab should close-on-exit or not close-on-exit, depending in fact on behavior of previously run command is very unintuitive, especially as default behavior. So I would propose to switch to "always" close-on-exit. If this is absolutely not possible, I guess my a ask would be to add this information (+ some info on this close-on-exit and mode differences, reason of this show exit code and how to change it) to the printed message next to `[process exited with code 9009 (0x00002331)] You can now close this terminal with Ctrl+D, or press Enter to restart.`, as typing some incorrect command (e.g. typing `rm some_file_name` in cmd.exe session by mistake instead of a WSL tab, then exiting it and starting a proper WSL tab) and then quitting with `exit` is fairly common. + in general, adding info on some known error codes of some standard Windows programs/utils would be nice

claunia commented

@vadimkantorov commented on GitHub (Dec 14, 2023):

Another extra proposed solution:
Make Ctrl+D shortcut to always close the tab uniformly across frequent profiles (cmd.exe/powershell/wslv1/wslv2), regardless of current exit code. And make cmd/powershell support Ctrl+D as well

Now, it's super funny, as stroking Ctrl+D in WSLv1 tab after command-not-found still prints 127 error code and invites to stroke Ctrl+D one more time :) sudo Ctrl+D as in xkcd comic strip

vadimkantorov@delldevadim:/mnt/c/Users/vadim$ asdsd
asdsd: command not found
vadimkantorov@delldevadim:/mnt/c/Users/vadim$
logout

[process exited with code 127 (0x0000007f)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

so currently Ctrl+D sends logout to terminal, which invites to press Ctrl+D one more time :)

@vadimkantorov commented on GitHub (Dec 14, 2023): Another extra proposed solution: Make Ctrl+D shortcut to always close the tab uniformly across frequent profiles (cmd.exe/powershell/wslv1/wslv2), regardless of current exit code. And make cmd/powershell support Ctrl+D as well Now, it's super funny, as stroking Ctrl+D in WSLv1 tab after command-not-found still prints 127 error code and invites to stroke Ctrl+D one more time :) `sudo Ctrl+D` as in xkcd comic strip ``` vadimkantorov@delldevadim:/mnt/c/Users/vadim$ asdsd asdsd: command not found vadimkantorov@delldevadim:/mnt/c/Users/vadim$ logout [process exited with code 127 (0x0000007f)] You can now close this terminal with Ctrl+D, or press Enter to restart. ``` so currently Ctrl+D sends `logout` to terminal, which invites to press Ctrl+D one more time :)

claunia commented