Terminal: exit doesn't reliably close the tab

[randomascii]

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.720]
Windows Terminal version (if applicable): Version: 0.10.781.0

Steps to reproduce

Use terminal preview for a while, then type exit to close the current tab

Expected behavior

The tab closes. This happens sometimes, particularly on a recently opened tab that hasn't been used much

Actual behavior

A "process exited" message is printed but the tab remains.

c:\src>exit
[process exited with code 2]

I don't know what triggers this - I cannot repro it on demand. I'll watch for it.

[zadjii-msft]

I _was_ going to give the usual closeOnExit pitch:

Alas, this is a behavior that's highly conserved across multiple shells and terminal emulators on most mainstream operating systems; more info in https://github.com/microsoft/terminal/issues/4223#issuecomment-574834181 and additionally https://github.com/microsoft/terminal/issues/5040#issuecomment-601855840. If you'd rather it just exit every time, set closeOnExit to always. :smile:

But then after re-reading, it seems peculiar to me that this would happen _sometimes_ and not other times. Maybe the process that's run immediately prior to exit is returning a non-zero exit code, and then we're picking that up from cmd when cmd exits?

[msftbot[bot]]

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!

[DHowett-MSFT]

Entering a nonexistent command then typing exit yields code 9009. I believe Terminal's broadly incapable of picking up somebody else's exit code -- it's holding a process handle for CMD, after all :smile:

[randomascii]

Ah. Exit codes indeed. Trying to run a nonexistent command and then type exit gives 9009. Typing "where asdfasdf" and then typing exit gives exit code 1. And so on.

"where asdfasdf" followed by "where notepad" followed by "exit" works (closes the tab)

[ossdesign]

I came here to search in regards to this one, as have been getting this for a little bit, just as "randonascii" puts it. I am not sure if this is normal or not, I am trying just now to read up on the "closeOnExit" stuff. A little over my head on the exit codes, but will figure out. I'll leave it in other's very capable hands!

[ossdesign]

Okay, I figured it out, found the resources online. Looks like exit codes can be used to evaluate the state that a run program exited as, maybe good for scripting. I just didn't know. Obviously you do, just saying ;) But yeah, seems like exiting via 'exit' when %ErrorLevel% != 0, then you get stuck with that error message, and you cannot break out of to close the terminal with the command line. You can still close the tab via clicking the X.

To the original poster, looks whatever you last did before trying to exit triggered a 'code 2':
"The system cannot find the file specified."

[randomascii]

I plan to tell people that this command sequence guarantees a clean exit:

cmd.exe /c echo ExitOnError=1 >%temp%\errorhandler.val && exit

It's true, and also deliciously misleading.

Vaguely related: twice I've seen a command prompt exit and print:

[process exited with code 1]

This is without my typing exit. I guess it has crashed?

[jdebp]

Using exit 0 avoids this behaviour of the Terminal. Yes, cmd is using the exit status of the last external command as the value for exit if you do not supply one.

[WSLUser]

This also happens sometimes with WSL.

[WSLUser]

I copied it this time. Strange thing though, I couldn't run any exe from WSL either.

wsluser@somecomputer:~$ cmd.exe
wsluser@somecomputer:~$ echo $PATH
/home/wsluser/.local/bin:/home/wsluser/bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/OpenSSH-Win64:/mnt/c/Program Files/PowerShell/7/:/mnt/c/Program Files/Microsoft VS Code Insiders/bin:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/Program Files/PuTTY/:/mnt/c/Users/user/.vcxsrv/vcxsrv.exe:/mnt/c/Users/user/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/user/AppData/Local/Programs/Microsoft VS Code Insiders/bin
wsluser@somecomputer:~$ ssh.exe
wsluser@somecomputer:~$ explorer.exe .
wsluser@somecomputer:~$ exit
logout

[process exited with code 1]

[WSLUser]

Since no errors popped up, I'm assuming the commands were piped to Windows but Terminal didn't handle them correctly.

[DHowett-MSFT]

Since no errors popped up, I'm assuming the commands were piped to Windows but Terminal didn't handle them correctly.

Windows Terminal doesn't "handle" commands. It gets text out of a stream and puts it on the screen, and gets user input from the keyboard and puts it into a different stream.

It looks like you're hitting an interop failure in WSL, which almost certainly warrants a bug filed on their repository.

The exit code from bash is, as always, the last exit code of the last command you tried to run with it. This is by design, and this behavior is highly conserved across many shells on a heap of different operating systems.

[WSLUser]

Usually I don't get exit codes to exit the tab. This time I did and got this interop error. It's working better than before at least (wsl.conf wasn't being read and interop was completely dead before unless I manually mounted my Windows drives in the CLI). Using an imported distro is more painful than one would think.

[sentry07]

Can we have the window close no matter what the code is? I've got an SSH client as one of my shells that connects to a machine and when I type "bye" on the remote machine, my window always says

[process exited with code 4294967295]

and won't close. I honestly don't care about the code. Just close the window. How can we do that?

(EDIT: Changed so that people don't think I'm patronizing)

[DHowett-MSFT]

_Yeah, you can. Set closeOnExit to always._

[DHowett-MSFT]

You do not need to be patronizing to make your point. (EDIT: It is possible I read "Just close the window. Can we do that?" in a way the author did not intend.)

[sentry07]

Yeah, wasn't trying to be patronizing. Just didn't know about the always option. Weird that you can set a field to either true or false, or a string value.

Just my opinion, I think "always" would be the preferred default option for most people. I've been a Windows user and software developer for over 25 years and couldn't think of a single instance in that time I wanted to know what exit code a shell or program closed with. I'm sure there's reasons people would want it, but just seems unnecessary by default.

Thanks for the quick response, though. :)

[DHowett-MSFT]

So, the main thing we were combatting is shells exiting immediately on open; it was one of the huge perceived reliability issues in versions pre-0.5 that was largely out of our control. We’ve got a plan on the books to make it more like ConEmu and only show you the message if the process eats it within five seconds of launching, but that one didn’t make the cut for 1.0.

Sorry for being so trigger-happy to call you out. 😄

[DHowett-MSFT]

(If you’re coming from a version of Terminal settings where closeOnExit is a Boolean value, it might be a great time to refresh your settings by moving them aside and letting us regenerate the file. The new defaults are a lot more sane than the old ones, but they might also change some things you’re relying on. YMMV.)

[randomascii]

Perhaps related: a couple of times a cmd window in the Windows Terminal (Preview) has spontaneously printed "[process exited with code 1]" without me typing exit. This seems to happen when I'm not even interacting with it. It feels like it has just randomly quit.

I have WER configured to get crash dumps and I haven't seen any so I don't know what's going on. It doesn't seem worth filing a bug because I have no real information, but I thought I'd mention it here.

[DHowett-MSFT]

Huh.. that could be a crash in the PTY host. Would you mind keeping your eyes peeled for OpenConsole dumps? This could be one of our known issues if it’s related to resizing (which I can’t immediately evoke by name on my phone.)

[Firehawke]

I don't know if I should open a new issue for this, but I'm starting to have issues with 'exit' causing WT as a whole to freeze. Before today's update it had started to randomly freeze on a 'exit' then after a few seconds the whole WT session would disappear. Now it's just freezing and staying that way.

As I see it, it's still a "exit doesn't reliably close the tab" kind of thing, so if I need to open a different issue, let me know.

[DHowett-MSFT]

@Firehawke We should definitely track that one as a separate issue! Would you mind capturing a dump file from Task Manager (WindowsTerminal.exe process) when it's hung like this? You can e-mail me with the address on my GitHub profile.

[Firehawke]

Okay, I'll open a new issue as soon as I'm able to trigger it again.

[vlad-teodor]

This also happens for me. I can reliably reproduce it with WSL (Ubuntu).
How to see the issue:

1. Without typing any command, press CTRL + D -> tab closes
2. Open another WSL tab
3. Type an invalid command ('frwgufgwe' should do)
4. Press CTRL + D -> "[process exited with code 127]"

[raxraj]

This is after the latest update the FIRST (without Preview) release.
And the exit command still doesn't appear to be fixed.

[zadjii-msft]

@raxraj as mentioned earlier in this thread:

Using exit 0 avoids this behavior of the Terminal. Yes, cmd is using the exit status of the last external command as the value for exit if you do not supply one.

You can also just set closeOnExit to always in your settings.json.

[HolisticDeveloper]

You can also just set closeOnExit to always in your settings.json.

For those that may not know, closeOnExit is a profile-specific setting. I had to go look up the settings schema docs to verify.

[raxraj]

@HolisticDeveloper @zadjii-msft Thanks, I understood. Solved the problem :)

[vadimkantorov]

Just got the same thing when closing a WSLv1 tab

What's bad is that it's completely unclear in the UI if WSLv1 is still running or not and what process exited with this exit code. I thought that some wrapper process is still running and typed Ctrl+C multiple times which does not work. Enter also doesn't work to close this. If it's Terminal that handles printing this message, the message should better include an explanation what happened and what's running / what's closed.

[DHowett]

That's fair. The message should say "the root process, wsl.exe, exited and reported an error code. everything underneath it has been either terminated or detached from the console".

Sorry, that's the best explanation we can give. :smile:

[vadimkantorov]

Well, this explanation is way better than the message that I got just minutes ago. At least it'd be clear that WSL is dead and that I should close the tab.

I thought some WSLv1 process (like Ubuntu's command_not_found that loads up python and does search for modules in a gazillion of site locations) got hung so badly that doesn't respond to Ctrl+C and blocked the WSL instance.