Using MSYS2 in Windows Terminal

[angelog0]

Has someone tried to use MSYS2 and friends (MinGW32/64) in the new Windows terminal? What would it be the MSYS2-profile?

Thanks...

[lazka]

Looks like you asked there too: https://github.com/microsoft/terminal/issues/1669

Did you get it working?

[angelog0]

This seems to work:

{
            "acrylicOpacity" : 0.5,
            "closeOnExit" : true,
            "colorScheme" : "base16-default-mod-lighten",
            "commandline" : "C:/msys64/home/user/wt-msys2.cmd -msys2",
            "cursorColor" : "#FD9D4F",
            "cursorShape" : "filledBox",
            "fontFace" : "DejaVu Sans Mono",
            "fontSize" : 11,
            "guid" : "{00000000-0000-0000-0000-000000000000}",
            "historySize" : 9001,
            "icon": "ms-appdata:///roaming/msys2.ico",
            "name" : "MSYS2",
            "padding" : "0, 0, 0, 0",
            "snapOnInput" : true,
            "startingDirectory" : "C:/msys64/home/user",
            "useAcrylic" : false
        },

where

$ cat .ms-terminal/wt-msys2.cmd
@echo off
setlocal

rem To activate windows native symlinks uncomment next line
set MSYS=winsymlinks:nativestrict

rem Shell types
if "x%~1" == "x-msys2" set MSYSTEM=MSYS
if "x%~1" == "x-mingw32" set MSYSTEM=MINGW32
if "x%~1" == "x-mingw64" set MSYSTEM=MINGW64

rem Shell types
rem set MSYSTEM=MSYS

C:\msys64\usr\bin\bash.exe --login -i

exit /b 0

May be we need to adjust the guid with uuidgen

[patstew]

Instead of a separate script you can just use: "commandline" : "cmd.exe /c \"set MSYSTEM=MINGW64&& C:\\msys64\\usr\\bin\\bash.exe --login\"", Note the lack of a space before &&. One problem is that bash does not seem to catch the SIGBREAK signal (I think that's what windows sends in place of SIGHUP?), so it doesn't save history on exit.

[angelog0]

@patstew, thanks for the suggestions, but it is not a separate script but the same .cmd with different options.

Thanks.

[patstew]

I was just pointing out you don't need any .cmd at all.

[sifivekevin]

Just noting here that one can define CHERE_INVOKING=1 and the profile will then honor the "startingDirectory" parameter. Like this:

"commandline" : "cmd.exe /c \"set CHERE_INVOKING=1&& set MSYSTEM=MSYS2&& C:\\msys64\\usr\\bin\\bash.exe --login\"",
"startingDirectory": "%USERPROFILE%\\git",

[angelog0]

OK, I tried this that seems to work:

"commandline": "cmd.exe /c \"set MSYSTEM=MSYS&& C:/msys64/usr/bin/bash.exe --login\""

and noticed that has:

$ echo $TERM                                                                                                            
cygwin

In MInTTY, instead it is xterm, so how can we set the same in Windows Terminal? May be other variable need to be imported..

See also this #2953.

[angelog0]

Let me know if we have to reclose this

[rkitover]

I just tried this too, and terminal things do not work, even if I manually set TERM=xterm-256color.

E.g. tmux says:

open terminal failed: not a terminal

colors in vim don't work, etc..

[pineman]

Colors are all broken for me too.

[angelog0]

@Restia666Ashdoll, also this works

"commandline" : "C:\\msys64\\usr\\bin\\bash.exe\" -i -l",

but you cannot set environment variables. For example, what do you use to start a MSYS2/MinGW64 shell?

This works for me:

"commandline": "cmd.exe /c \"set MSYSTEM=MINGW64&& set MSYS=winsymlinks:nativestrict&& C:/msys64/usr/bin/bash.exe --login\"",
"hidden": false,
"startingDirectory": "C:/msys64/home/user",

and similar for MSYS2, MSYS2/MinGW32 shells.

[rkitover]

@Restia666Ashdoll try forward slashes.

While these methods may work for people for git, we still need an actual fix for the terminal to work correctly as a terminal.

[Witchilich]

If you install them with scoop install msys2, you can just use this

        {
            "acrylicOpacity" : 0.75,
            "closeOnExit" : true,
            "colorScheme" : "flat-ui-v1",
            "commandline" : "cmd /c msys2",
            "cursorColor" : "#FFFFFF",
            "cursorShape" : "bar",
            "fontFace" : "Consolas",
            "fontSize" : 10,
            "historySize" : 9001,
            "icon" : "%SCOOP%\\apps\\msys2\\current\\msys2.ico",
            "name" : "MSYS2",
            "padding" : "0, 0, 0, 0",
            "snapOnInput" : true,
            "startingDirectory" : ".",
            "useAcrylic" : true
        },
        {
            "acrylicOpacity" : 0.75,
            "closeOnExit" : true,
            "colorScheme" : "flat-ui-v1",
            "commandline" : "cmd /c mingw64",
            "cursorColor" : "#FFFFFF",
            "cursorShape" : "bar",
            "fontFace" : "Consolas",
            "fontSize" : 10,
            "historySize" : 9001,
            "icon" : "%SCOOP%\\apps\\msys2\\current\\mingw64.ico",
            "name" : "MinGW64",
            "padding" : "0, 0, 0, 0",
            "snapOnInput" : true,
            "startingDirectory" : ".",
            "useAcrylic" : true
        },

[lamuertepeluda]

My config (with windows PATH included --> vscode and other stuff can work), notice MSYS2_PATH_TYPE

    {
      "acrylicOpacity": 0.75,
      "closeOnExit": true,
      "colorScheme": "Campbell",
      "commandline": "cmd.exe /c \"set MSYSTEM=MINGW64&& set MSYS=winsymlinks:nativestrict&& set MSYS2_PATH_TYPE=inherit&& C:/msys64/usr/bin/bash.exe --login\"",
      "cursorColor": "#FFFFFF",
      "cursorShape": "bar",
      "fontFace": "Consolas",
      "fontSize": 10,
      "guid": "{1597a4d0-b666-4b1f-a8d3-79af62638679}",
      "historySize": 9001,
      "icon": "C:\\msys64\\msys2.ico",
      "name": "MSYS2",
      "padding": "0, 0, 0, 0",
      "snapOnInput": true,
      "startingDirectory": "%USERPROFILE%",
      "useAcrylic": true
    }

MSYS2 configuration thanks to this great article

[machsix]

Sadly, this doesn't give me a terminal with 256 colors. My configuration

        {
            "guid": "{75529e5d-bde6-4848-85f4-d73c3838a5f5}",
            "name": "MinGW 64",
            "commandline": "cmd.exe /c set MSYSTEM=MINGW64 && c:/msys64/usr/bin/bash --login -i",
            "cursorColor": "#FFFFFF",
            "cursorShape": "bar",
            "hidden": false,
            "icon": "C:\\msys64\\msys2.ico",
            "fontFace": "Cascadia Code",
            "startingDirectory": "%USERPROFILE%"
        },

I used the test script here https://askubuntu.com/questions/821157/print-a-256-color-test-pattern-in-the-terminal

I think it is related to this one https://github.com/microsoft/terminal/issues/2837 https://github.com/msys2/MSYS2-packages/issues/1771

[Witchilich]

Works here

[TBBle]

Those're two different tests. The pipe-to-bash test from @machsix 's link is generating blocks use "Set Background Colour to x" (SGR 48) for x in the range 1-255 (i.e. 256-colour palette).

The one-liner used by @Restia666Ashdoll is iterating through the 9 terminal styles, for each of the eight foreground colours and eight background colours (i.e. 8/16 colour palette, since usually 'bold' in that palette means a second set of 8 colours, traditionally brighter versions of the first 8).

@Restia666Ashdoll's script for easy cut-and-paste.

for x in {0..8}; do for i in {30..37}; do for a in {40..47}; do echo -ne "\e[$x;$i;$a""m\\\e[$x;$i;$a""m\e[0;37;40m "; done; echo; done; done; echo ""

256-colour support is definitely an issue about MSYS2 or bash or cygwin interacting with ConPTY, since I can do:

curl -s https://gist.githubusercontent.com/HaleTom/89ffe32783f89f403bba96bd7bcd1263/raw/ | bash > 256col.ans
cat 256col.ans

and see the same result as @machsix, but outputting the same file (256col.ans) under PowerShell Core in MS Terminal or directly, (or MSYS in MinTTY) shows the intended result.

The same problem shows up if I run PowerShell Core directly (rather than inside MS Terminal) and then start MSYS in-place with

C:\msys64\msys2_shell.cmd -no-start -defterm

Given that the foreground text on 30, 31, 32, and 33 have come out differently, but all used the same command (\e[38;5;15m), I guess something is incorrectly mangling the ANSI sequences, as they're acting like they saw \e[30m, \e[31m,\e[32m,\e[33m. However, the entire rest of the test is acting like it saw the same foreground colour, and for some reason is using the supplied foreground colour as the background in every case.

[TBBle]

Another good test to show it's something about cygwin and Windows ConHost is https://github.com/Maximus5/ConEmu/blob/master/Release/ConEmu/Addons/AnsiColors256.ans. In the faulty case, you see a bunch of \, which are actually part of an escape sequence.

And looking again at microsoft/terminal#2837, that's almost certainly the issue. https://conemu.github.io/en/CygwinAnsi.html is a good description of the underlying issue.

[TBBle]

To bring it back to MSYS, fhandler_console::char_command in cygwin.dll is the code that tries to translate CSI sequences, e.g., SGR as we're discussing here, into ConHost commands. It does this through a table mapping the 256-colour palette down into the the 16-colour palette used by the Windows Console CHAR_INFO structure (see table256).

It's not obvious what goes wrong, since the first row of that table is the same as the values for 30-37, then again with bold added, so something else must be mangling the sequences.

It's also possible the parsing itself (fhandler_console::write, the code that calls char_command) is faulty. This seems likely because the output of the \ in the AnsiColors256.ans test points to a failure in gotrsquare, eatpalette, endpalette, which is part of the same parser.

[TBBle]

Trying to track this down, it seems that there's a value wincap.has_con_24bit_colors() which controls whether TERM is set to xterm (true) or cygwin (false), see msys2/Cygwin@bd627864ab4189984cdb0892c00f91e39c4e8243.

I'm definitely getting TERM as cygwin on my Windows 10 1909 desktop machine when run under Terminal or from PowerShell Core, but not from mintty.

Ah! The msys-runtime package is still on Cygwin 3.0.7, and the change above for 24-bit colour support in Windows landed in Cygwin 3.1, along with Pseudo Console support which (I think) removes the need for the winpty tool.

So for 24-bit colour support in Windows Terminal, we need to upgrade msys-runtime, which I think should be a separate bug report from this one.

As far as the original question, I'm using the simple solution from the other ticket

"commandline" : "C:/msys64/msys2_shell.cmd -defterm -no-start -msys2"
"commandline" : "C:/msys64/msys2_shell.cmd -defterm -no-start -mingw64"
"commandline" : "C:/msys64/msys2_shell.cmd -defterm -no-start -mingw32"

[stania]

Any changes there?

[rkitover]

As @TBBle said, we need someone to update the msys2 runtime to the latest cygwin version.

Any volunteers?

[Biswa96]

The new conpty interface in cygwin is not complete yet. New issues pop up everyday as well as new patches.

[rkitover]

All the terminal stuff is still kind of buggy. I have been using mostly powershell 7, with the new terminal and over ssh, and I see all kinds of weird issues with things like the native vim in various configurations. Sometimes it works perfectly, other times it misaligns everything and puts stars around words, other times it takes up only half the terminal, etc. etc.. I just end up using whichever version of vim or neovim works in that configuration.

I'd love to be able to use the new terminal with msys2, and do things like start an msys2 shell from a native sshd powershell session etc..

[rkitover]

Perhaps the cygwin terminal stuff may not be perfect, but better than nothing for a lot of people.

@Alexpux how do you feel about this? Would it helped if we made a PR (and tested it thoroughly of course) to merge the latest cygwin runtime?

[yihuajack]

What's the difference between bash.exe --login and bash.exe --login -i?

[Biswa96]

From man bash:

-i        If the -i option is present, the shell is interactive.
-l        Make bash act as if it had been invoked as a login shell (see INVOCATION below).

[rkitover]

I have a fully functional workaround for this issue here:

https://github.com/rkitover/windows-alt-sshd-msys2

this uses ssh to connect to an MSYS2 sshd on an alternate port.

The script does all the necessary setup for you.

[henrikx]

This is super buggy for me. When using fish as the shell and trying to tab complete it starts looking like this.

And it gets worse with each time I press tab.

It only works correctly in mintty as far as I've seen.

Just for reference, this is what it looks like in mintty, which is what it should look like.

I have not yet tried @rkitover's script, but honestly it's a workaround at best.

Edit: This does not only happen Windows Terminal. It seems to happen with anything else than mintty. I've tried Cmder, Fluent Terminal and Hyper. I don't know if there is something I'm missing. They were all pointed to launch /usr/bin/fish.exe --login -i.

[henrikx]

Setting TERM to rxvt fixed quite a few issues with rendering in things like cfdisk.

Interestingly xterm-256color caused way more issues than it solved, even though Windows Terminal speaks xterm. Wrong or missing colors and mishandled input.

Autocomplete issue remains in fish though.

I think this issue is related https://github.com/microsoft/terminal/issues/1647, but it is marked as solved, however something similar seems to happen:

However I think this is the real issue: https://github.com/microsoft/terminal/issues/150, which resides in conhost, which would make a lot of sense because those other terminals also use conhost.

[rkitover]

@henrikx the real issue is that msys2 is using an old cygwin runtime that does not support the new windows terminal capabilities, and only the supports the old "cygwin" terminal type. See discussion above.

[henrikx]

@rkitover I agree that using ConPty would very likely solve this, however am I wrong to think that the bug in conhost is the real reason it does not work as it should? I feel like that is what is ultimately misinterpreting the cygwin terminal's output, which is why mintty works, but conhost does not. Using ConPty would likely fix it, because then you're no longer using legacy conhost, but the new implementation instead.

[TBBle]

Per my research on https://github.com/msys2/MSYS2-packages/issues/1684#issuecomment-570797809, it appeared that there's a fault in Cygwin's parsing of ANSI sequences when converting them into conhost sequences.

My earlier link to fhandler_console::chart_command was for Cygwin master. Cygwin 3.0.7's fhandler_console::chart_command looks the same apart from the added 256-colour support.

Looking at the history of that file (somehow _msys2-3_14-release is ahead of master) there are a few workarounds post-3.0.7 for cursor location and horizontal tab issues in conhost, which might be what's causing the issue in @henrikx's latest screenshot, particularly if window resizing has been involved.

@henrikx: https://github.com/microsoft/terminal/issues/150 only affects CJK Windows builds. Is your system set up for CJK? I'm not sure if there are actually specific builds for those countries, or if it just means having the legacy character set and/or localisation configuration set for China, Japan, or Korea.

[henrikx]

@TBBle That is a good point. My locale is set to Norwegian, but the display language is English. Maybe it is not the real issue, but it just seemed very similar to what I'm experiencing.

For now I'm using Cygwin and that works perfectly, so I'll just keep using that for now.

Thanks.

[RealKC]

Has anyone looked into why tmux does not work with Windows Terminal?

[TBBle]

msys2-runtime has been upgraded to 3.1.4-3, and 256 colour support is now working in MSYS2 under Windows Terminal, giving identical results for the 256col.ans file as given under PowerShell Core:

Worth checking if any other character-corruption issues are resolved (or changed) by this, e.g. @henrikx 's issue with fish, or @RealKC 's issue with tmux.

Also, not Windows Terminal-specific, but it does appear that winpty is not needed, briefly tested using my windows install of Python 3.6. (Huh... I need to upgrade that)

[RealKC]

I've just updated and it doesn't seem like the issue with tmux is fixed

[Biswa96]

Try to set the MSYS=enable_pcon environment variable before running any msys2 instances.

[RealKC]

That didn't seem to work

This is how my fish profile for the Windows Terminal looks like

            {
                "guid": "{6ceca674-992f-453a-bb2f-6f5499e32d96}",
                "name": "fish",
                "commandline": "cmd /c \"set MSYSTEM=MSYS&& set MSYS=winsymlinks:nativestrict&& set MSYS2_PATH_TYPE=inherit&& set enable_pcon=1&& C:\\msys64\\usr\\bin\\fish.exe -i -l\"",
                "hidden": false,
                "startingDirectory": "C:\\msys64\\home",
                "icon": "C:\\msys64\\home\\favicon.ico"
            }

if that helps with anything

[DJviolin]

@TBBle Can you share this ANSI table's download link? I didn't found in my MSYS2 or ConEmu install.

[TBBle]

@DJviolin I mentioned it earlier:

curl -s https://gist.githubusercontent.com/HaleTom/89ffe32783f89f403bba96bd7bcd1263/raw/ | bash > 256col.ans

Edit: Read the file first. Don't trust me and pass random Gists through bash. ^_^

[TBBle]

@RealKC enable_pcon is like winsymlinks, so it is added to the MSYS env-var. Try:

            {
                "guid": "{6ceca674-992f-453a-bb2f-6f5499e32d96}",
                "name": "fish",
                "commandline": "cmd /c \"set MSYSTEM=MSYS&& set MSYS=winsymlinks:nativestrict:enable_pcon&& set MSYS2_PATH_TYPE=inherit&& C:\\msys64\\usr\\bin\\fish.exe -i -l\"",
                "hidden": false,
                "startingDirectory": "C:\\msys64\\home",
                "icon": "C:\\msys64\\home\\favicon.ico"
            }

[TBBle]

To avoid having a cmd (and hence conhost) running for each bash, I've just changed my shortcuts to use the following command line, as part of ensuring enable_pcon is set:

//"commandline": "\"C:/msys64/msys2_shell.cmd\" -defterm -no-start -msys2",
"commandline": "C:/msys64/usr/bin/env.exe MSYS=enable_pcon MSYSTEM=MSYS /bin/bash --login",

//"commandline": "\"C:/msys64/msys2_shell.cmd\" -defterm -no-start -mingw64",
"commandline": "C:/msys64/usr/bin/env.exe MSYS=enable_pcon MSYSTEM=MINGW64 /bin/bash --login",

//"commandline": "\"C:/msys64/msys2_shell.cmd\" -defterm -no-start -mingw32",
"commandline": "C:/msys64/usr/bin/env.exe MSYS=enable_pcon MSYSTEM=MINGW32 /bin/bash --login",

It'd be even nicer if you could add env-vars to a profile, but I don't believe that's supported (yet). I might put in a feature request for it, or just have a go at implementing it myself one day.

[TBBle]

Poking about, I suspect tmux won't work as tty reports a different device (/dev/consX) under WT than it does under mintty (/dev/ptyX). You can also see this with ps -s while you have a bash running under WT and one under mintty.

Interestingly, strace -o /dev/null tty reports the /dev/consX on both WT and mintty, and strace -o /dev/null tmux reports the same failure "open terminal failed: not a terminal" on both WT and mintty.

That makes it really hard to debug, 'cause I can't examine a working tmux instance.

So it's something down in the cygwin layer, perhaps tied to mintty support somehow?

[RealKC]

Interestingly both tty and strace -o /dev/null tty report /dev/ptyX on my machine under MinTTY, and both /dev/cons0 under WT.

[TBBle]

Ah. I had MSYS=enable_pcon set in my msys2.ini. Removing it also gives the same result in mintty with and without strace. That's why it was different.

[TBBle]

It seems like under WT, it's always enable_pcon, and with mintty, enable_pcon only affects the tty of things like gdb and strace. Assuming that enable_pcon's difference is "it makes the tty a console instead of a pty"... I really don't have any other behaviour differences in enable_pcon, I couldn't replicate the failures described in the commit that made disable_pcon the MSYS2 default.

I wonder if upstream Cygwin under Windows Terminal reflects the same tty behaviour, or if tmux works there somehow.

[henrikx]

I get the same error in cygwin.

[chuxubank]

Works here

How to get mingw64 mini icon?

[mapitman]

How to get mingw64 mini icon?

See this line in my profiles.json file https://gist.github.com/mapitman/9c2c0a0f8f6e65475d210817e2be6a82#file-profiles-json-L21