Exiting MSYS2 shells in Windows Terminal sometimes causes "Terminate batch job (Y/N)" on Ctrl-D?

[sdbbs]

I use Windows Terminal mostly to run MSYS2/MSYS or MSYS2/MINGW64 (bash) shells; I have them set up as per instructions in https://www.msys2.org/docs/terminals/ - basically, in setting.json under "profiles" key you might have:

    {
      "guid": "{71160544-14d8-4194-af25-d05feeac7233}",
      "name": "MSYS / MSYS2",
      "commandline": "C:/msys64/msys2_shell.cmd -defterm -here -no-start -msys",
      "startingDirectory": "C:/msys64/home/%USERNAME%",
      "icon": "C:/msys64/msys2.ico",
      "font": 
      {
        "face": "Lucida Console",
        "size": 9
      }
    },

This mostly works for me - apart from one thing:

If I start a new tab, then do not do anything there, and I want to exit immediately, I just do:

• press CTRL+D - I see a brief text "logout", and then the shell and the terminal tab exits

... which is great, exactly as I want it to.

But then, if I do work in the terminal for some hours (and I cannot tell exactly what triggers this condition), and then I want to exit the shell/terminal tab - the following happens:

• press CTRL+D - I see a brief text "logout", and shell/terminal tab appears to exit
• However, the tab doesn't exit, instead previous text gets deleted, and I get "Terminate batch job (Y/N)" prompt
• Regardless of if I type Y or N, I get [process exited with code 1 (0x00000001)] and the tab remains
• Great, now I have to do even more work, and click the little X on the tab, to have the tab close

All I want, is to just do one thing - CTRL+D - and have the shell close properly, and the corresponding terminal tab to exit. Is there anything I can do in my setup, to ensure that these tabs close immediately always on CTRL+D?

---

EDIT: possibly related: microsoft/vscode#45693 (even though, as far as I can see, here I do not explicitly use anything called "winpty")

[DHowett]

So, yup, that is definitely weird.

At the heart of the issue is MSYS's use of a batch file with (potentially) improper signal handling characteristics. I'm not sure what they're setting up in there; however, we should probably support whatever it is so they don't need to ship a batch file!

That message only really originates when CMD² receives a ^C¹ while running a batch file. I'm sure it's slightly more complicated than that, but I have spent enough time this week reading CMD's source code.

Apart from trying to change how you spawn MSYS, the only knob Terminal really offers here takes effect a little too late to address your main pain point. That knob is to set "closeOnExit": "always" for your MSYS profiles. All it can do is make sure that the tab closes after it displays the "process exited with code" message. Up until that point, from Terminal's perspective, the thing it launched (cmd) is still running.

¹ Or a CTRL_C_EVENT; if somebody is sending one, CMD will react in the same way.
² Which is running because it's interpreting the batch file that spawns MSYS' shell.

[ipaqmaster]

This is really annoying so I ended up tracing C:\msys64\msys2_shell.cmd to find out what it's evaluating by the end so I can call that instead.

MSYS2 advertise two launch options for Windows Terminal. One is UCRT64 / MSYS2 which calls C:/msys64/msys2_shell.cmd -defterm -here -no-start -ucrt64 and the other is MSYS / MSYS2 which calls the same thing but the last argument is -msys instead of -ucrt64.

Despite that slightly different launch option they both identically run C:\msys64\usr\bin\bash -l but with different variables.

The unique variables for UCRT64 which matter are:

CONICON=ucrt64.ico
CONTITLE=MinGW UCRT x64
MSYSTEM=UCRT64

And the unique variables for the MSYS launch option are:

CONICON=msys2.ico
CONTITLE=MSYS2 MSYS
MSYSTEM=MSYS

(Both also contain unrelated unique variables for WT_PROFILE_ID and WT_SESSION too.)

The most important feature and difference between the two are their MSYSTEM variables. This variable influences the environment that bash will load into once invoked at the end of the batch script. Bash achieves this by reading /etc/profile which is specially designed for MSYS2 to load a unique configuration based on the MSYSTEM variable for easy flipping between the environments MSYS2 provides. This paragraph of mine is influenced by this source page which explains better.

To avoid creating various shortcuts just to set these two variables, I've changed the "Command line" entry for each of my MSYS2 Windows Terminal shells (UCRT64 and MSYS) to just run C:\msys64\usr\bin\bash.exe -l -c 'MSYSTEM=UCRT64 ; bash' and C:\msys64\usr\bin\bash.exe -l -c 'MSYSTEM=MSYS ; bash' as per the above output, but am setting each MSYSTEM variable respectively and running uname does appear to be consistent with these new launch options.

Now Windows Terminal is actually running bash directly itself and I can still access both MSYSTEM types just fine. Avoiding this Terminate batch job (Y/N) prompt from their decision to wrap shell spawning in a bat script.

---

E: I've gone to compile things and realised the above wasn't enough for /etc/msystem to initialise the environment correctly. I've put together this cmd launch command chain which works much better for Windows Terminal instead: C:\Windows\System32\cmd.exe /C "set MSYSTEM=MINGW64&& start /B C:\msys64\usr\bin\bash.exe -l". This correctly sets the variable for bash to run /etc/msystem and configure the environment appropriately, especially important for building software.

According to /etc/msystem at the time of writing - valid options for the MSYSTEM variable are: MINGW32, MINGW64, CLANG32, CLANG64, CLANGARM64 and UCRT64. Any other value will cause /etc/msystem to set generic variables. You also make sure there's no space after the variable name and the && otherwise /etc/msystem will fail to match due to the trailing whitespace on the variable.

To finish off, here are my two profiles for MINGW64 and MSYS in Windows Terminal for easy pasting:

Click to reveal json

          {
              "bellStyle": "none",
              "closeOnExit": "always",
              "commandline": "C:\\Windows\\System32\\cmd.exe /C \"set MSYSTEM=MINGW64&& start /B C:\\msys64\\usr\\bin\\bash.exe -l\"",
              "font": 
              {
                  "face": "Lucida Console",
                  "size": 9.0
              },
              "guid": "{65b1be9b-7451-410d-a229-8557e8b9fea9}",
              "hidden": false,
              "icon": "C:/msys64/mingw64.ico",
              "name": "MINGW64 / MSYS2",
              "startingDirectory": "%USERPROFILE%"
          },
          {
              "bellStyle": "none",
              "closeOnExit": "always",
              "commandline": "C:\\Windows\\System32\\cmd.exe /C \"set MSYSTEM=MSYS&& start /B C:\\msys64\\usr\\bin\\bash.exe -l\"",
              "font": 
              {
                  "face": "Lucida Console",
                  "size": 9.0
              },
              "guid": "{65b1be9b-7451-410d-a229-8557e8b9feaa}",
              "hidden": false,
              "icon": "C:/msys64/msys2.ico",
              "name": "MSYS / MSYS2",
              "startingDirectory": "%USERPROFILE%"
          },

E2:

As @angelog0 has mentioned on msys2/MSYS2-packages#1684 (comment) ; With Windows Terminal 1.18+ you can set variables right in the terminal startup. Much cleaner looking profiles without needing to juggle cmd.exe prior.

[NullDott]

Hey, I was just looking at this discussion after my Windows Terminal started to ask me to "terminate batch job" too, the solution provided by @ipaqmaster plus the "closeOnExit": "always" option seemed to fix the problem for the Windows Terminal, however, the issue persists in VSCode as the integrated shell profile.

I used the instructions from the MSYS2 docs, but in VSCode it asks me to terminate the batch job when closing the terminal emulator, and it also shows me this error:

Is there any fix for VScode? I want to use msys2 as my default profile, but this makes it annoying...

[angelog0]

I just use this (there are some years now) and it works (no need of .bat or .cmd files):

[...]
"defaults":
        {
            "closeOnExit": "graceful",
            "cursorShape": "filledBox",
            "font":
            {
                "face": "JetBrainsMono Nerd Font",
                "size": 11
            },
            "hidden": false,
            "historySize": 9001,
            "padding": "8, 8, 8, 8",
            "snapOnInput": true
        },

        "list":
        [
            // Each item is in alphabetical order. Does it mean it is logical?
            {
                "colorScheme": "MSYS2-Theme",
                "commandline": "C:/msys64/usr/bin/bash --login",
                "environment":
                {
                    // We need the following to duplicate a tab in the same folder
                    "CHERE_INVOKING": "1",
                    "MSYS": "winsymlinks:nativestrict",
                    "MSYS2_PATH_TYPE": "inherit",
                    "MSYSTEM": "MSYS"
                },
                "guid": "{9c173dff-f524-43df-b40e-29953998c744}",
                "icon": "C:/msys64/msys2.ico",
                "name": "MSYS2 MSYS Shell",
                "startingDirectory": "C:/msys64/home/%USERNAME%"
            },
[...]

[NullDott]

Yeah, I use the same, I read the issue you quoted and it works.

I was asking if there was a similar solution for the VSCode terminal emulator.

Because MSYS2 in the windows terminal works perfectly, but in VSCode keeps throwing me that error

[angelog0]

@NullDott, my solution does not use msys2_shell.cmd so there is not batch job to terminate in any case.

[NullDott]

Could you share me your VSCode terminal profile config for MSYS?

[angelog0]

I do not use VSCode. If you get the message to terminate batch job and do not use msys2_shell.cmd to use MSYS2 in WT, the message comes from elsewhere.

[NullDott]

I see, thanks then!

[sdbbs]

I tried quickly the setup by @angelog0 in #14663 (comment) - and I just start MSYS2, Hit Ctrl-D, and I get:

$
logout

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

Now I have to press Ctrl+D yet another time - how irritating ...

[DHowett]

Then change "close on exit" to "always"?