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 #4223 (comment) and additionally #5040 (comment). If you'd rather it just exit every time, set closeOnExit to always. 😄

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?

[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 😄

[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]

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

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

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

[LuckyGinger]

Not to beat a dead horse but check the docs:
https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-settings#how-the-profile-closes-when-exiting

closeOnExit to always specifically under the profiles.defaults section of settings.json fixed it for me.

Cheers,

[vadimkantorov]

Again stumbled on this. After typing Ctrl+D in WSLv1 shell it hung and did not close the tab:

[zadjii-msft]

Yep, that's exactly the same as all the other hits in this thread. You can totally avoid it with "closeOnExit": "always". I'm not sure there's any other discussion to be had on the subject?

[vadimkantorov]

Sometimes it exits and closes the tab, sometimes not. When it doesn't close the tab (because of whatever non-zero code or another reason), I propose it should print some clear explanation what process is talked about and why the tab isn't closed automatically so that I don't have to google it another time when it happens in a few months...

[erm3nda]

I've read that closeOnExit is a profile especific feature. Seems not anymore, I've edit the settings.json and defined the setting in general (not inside the profiles part) and worked. That should be default behavior.

[DHowett]

I've read that closeOnExit is a profile especific feature. Seems not anymore, I've edit the settings.json and defined the setting in general (not inside the profiles part) and worked. That should be default behavior.

You will probably find, next time you Save your settings using the UI, that it deletes that key from the general section. It is not expected there, and it will be ignored. :)