MSYS2-packages
MSYS2-packages copied to clipboard
msys2
Using MSYS2 in Windows Terminal
Has someone tried to use MSYS2 and friends (MinGW32/64) in the new Windows terminal? What would it be the MSYS2-profile?
Thanks...
Looks like you asked there too: https://github.com/microsoft/terminal/issues/1669
Did you get it working?
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
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.
@patstew, thanks for the suggestions, but it is not a separate script but the same .cmd with different options.
Thanks.
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",
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.
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..
@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.
@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.
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
},
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
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
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.
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.
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.
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"
As @TBBle said, we need someone to update the msys2 runtime to the latest cygwin version.
Any volunteers?
The new conpty interface in cygwin is not complete yet. New issues pop up everyday as well as new patches.
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..
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?
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).
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.
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.
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.