-
Notifications
You must be signed in to change notification settings - Fork 816
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More nonzero exit codes when trying to exit a WSL instance lately #4989
Comments
I can reliably reproduce Steps:
The session stays open, and displays
In case it's helpful, I don't have any Terminal keybindings set for the letters |
Does the behavior change when you omit "commandline" and change "name" to "WLinux"?
I know why you did that, just curious if the change is because you are calling it by wsl.exe instead of the name. |
No difference in behaviour @sirredbeard. I also realised I can replicate by clicking I just tried using the raw Pengwin console, instead of Windows Terminal and was unable to replicate. So it only happens within Windows Terminal. I'm on Version: |
I also just confirmed the same |
I can reproduce the code 130: By calling Ubuntu via the command line method you are using:
But not when Ubuntu or other distro is called this way:
Repeated same with my Ubuntu 20.04 test image:
But not:
Can you post your profiles.json? I suspect this is some interaction between how WSL is being launched within Windows Terminal. |
I don't think this is a WSL bug - or at least my It will be interesting to see if Aaron's error is linked to Terminal like mine, or something completely different. |
Looks like it's the intended Windows Terminal behaviour: microsoft/terminal#4223 |
@valorin @sirredbeard I haven't been able to consistently reproduce this bug, so I'm not sure… but I looked at microsoft/terminal/#4223 and it just doesn't seem right for ^D to not work for Linux-in-WT… because it works in Terminal-on-Linux, that way… so why not here??? |
Put a copy of my profiles.json up. |
The cause in my case is that WT detects an error code was returned by the last command. So when you click ^D and it goes to close the tab, it checks for an error code from the last command first. As of v0.8, WT prevents itself from closing a tab when there is an error code, to avoid the problem where the tab throws an error when it's first launched. If it auto-closed, a broken profile would open and close quickly and you'd miss the error code. It may be different in your case, but in every test I ran, it always displayed the error when the last command didn't close cleanly. |
One of the discussions in the WT issues explains that the gnome terminal handles the ^D differently than they can in WT. Hence the different behaviour. I'll try to find it for you when I'm back at my computer. |
Ah this is the comment I'm thinking of: microsoft/terminal#4223 (comment) |
Just for the record, it isn’t related to WT “handling” Ctrl+D differently. Terminal tracks exactly one process and reports on its exit code. In all WSL cases, that process is Your shell is reporting, by using This is how |
@DHowett-MSFT , I wonder if it could be possible to allow the user to specify a list of exit statuses to be considered "fatal", and close the tab if none of those is observed? |
I have set |
Thx to both @DHowett-MSFT and @yveslange . The former for explaining why this happens (and that it "works as intended"), and that I didn't broke my WSL installation somehow. The latter for providing a means to handle it the way that suits my needs. |
@yveslange That did the trick. |
As noted previously I can confirm having the |
User reports increased frequency of non-zero exit codes when exiting WSL in Ubuntu 18.04:
Second user confirms in Pengwin.
I am re-directing conversation here.
Aaron and Stephen could you please provide steps to reproduce?
Aaron I see in your screenshot that you have SSH'd into a remote server, shut it down, and then exited that shell. I am curious how did you spawn that shell though?
When I exit a shell in Windows Terminal it normally closes the terminal. Are you launching it in Windows Terminal? With a custom entry by chance? What do you have in the Windows Terminal entry for that shell?
The text was updated successfully, but these errors were encountered: