Arrow keys broken in msys2 bash programs after installing Terminal

[akrieger]

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.815]
Windows Terminal version (if applicable): 1.0

Any other software? msys2 bash version 4.4.23(2)-release (x86_64-pc-msys)

Steps to reproduce

0. Note I also did an msys upgrade, which did upgrade msys2-runtime (3.0.7-6 -> 3.1.4-2). Not sure if that triggered this or installing Windows terminal did. I cannot find a way to safely revert my msys2-runtime package to confirm.
   0a) Edit: Reverting msys2-runtime did not resolve the issue.
   0b) Edit2: The same thing happens if I run bash directly via ConEmu with -new_console:p5
1. Install msys2
2. Run cmd.exe
3. Run C:\<msys2 install path>\usr\bin\bash.exe --login -i
4. Try to use an application that responds to arrow keys like less or vim
5. Note that the applications do not respond to arrow keys
6. In cmd.exe settings, select 'Use legacy console'
7. Repeat 2-4 after restarting cmd.exe, observe applications respond to arrow keys again

Expected behavior

• less and vim and etc should respond to arrow keys (less should scroll, vim cursor should move)

Actual behavior

less, vim, etc. do not respond to arrow keys at all. bash history however does correctly respond, interestingly.

Side notes

For completeness, the full list of packages I upgraded before experiencing this issue: https://gist.github.com/akrieger/f3f7bdc38f22e663d156526ea94df839

[akrieger]

I found #4949 but it was hard to understand exactly everything going on in there, so I decided to make a new issue and we can merge if it's fundamentally the same behavior/issye that's being described in there, instead of adding noise permanently to that task if it's not.

[akrieger]

Through some combination of resetting settings, switching back and forth between legacy console and new console, resetting ConEmu to default (although my repro conditions didn't involve ConEmu), and setting TERM=cygwin unconditionally in my ~/.bashrc, I've managed to make the problems (seemingly) go away. I'll consider myself lucky and just move on with life.

[DHowett]

So this worries me more than you having the problem to begin with 😉

How long have you been forcing TERM=cygwin? Was that a new change?

msys 3.1 contains the runtime changes from cygwin 3.1. Cygwin 3.1 no longer treats the windows console as term=cygwin (it prefers TERM=xterm-265 now).
If you were setting TERM=cygwin across an MSYS upgrade, there's a chance applications were still expecting data from the cygwin console translator.

[akrieger]

To directly answer your question: TERM=cygwin was my ultimate fix to the problem. I only set it at the end of my debugging. Until then the TERM setting was... whatever it was inheriting from the environment. Including when I did the msys upgrade. The issues also persisted across reboots after uninstalling/reinstalling WT, as I was trying really hard to make sure it wasn't some stale state issues.

So, the full order of events was:

1. I installed Windows Terminal
2. Played with it, tried to use bash from within it, decided it wasn't for me.
3. Went back to my regular setup using bash directly in conemu (not via the conemu connector)
4. Realized things were broken (arrows etc weren't working)
5. ??? did an msys upgrade (pasted the upgrade log in the bottom of my report)
6. Realized it still wasn't working
   6a) Started panicking.
7. Tried uninstalling Windows Terminal.
8. Tried to debug if it was a conemu thing vs a bash/cmd thing. Repro'd in cmd.exe
9. Somehow ended up in cmd.exe settings, found the toggle for 'use legacy console', toggled it.
10. Found that worked, sorta. Got arrow keys back, but home/end didn't work.
11. Reported issue, kept debugging.
12. Eventually found some internet reports from like 2018 talking about TERM=xterm-256color causing issues with ncurses? And also maybe newer reports? Which is what led me to playing with the TERM setting.
13. Through some amount of flailing including trying to install pdcurses instead of ncurses, found that setting TERM=cygwin in my bashrc, plus resetting all ConEmu settings, and disabling ConEmu xterm/ansi sequence handling (but still injecting the conemu dll into child processes) got me to a working state including full ANSI colors (which weren't working before) despite not using the ConEmu connector, just directly invoking bash.exe.
14. Decided to listen to my first rule of making pottery: 'stop touching it'.

I'm spookum, I tell you what.

[akrieger]

So I did a clean msys2 install just to be sure, and yeah unless I set TERM=cygwin in my .bashrc many programs just seem to fall over head. I think the precipitating moment was installing WT which changed the default conhost (maybe? Not really sure if that's what happens when WT is installed), which then changed the default value of $TERM in my environment which then broke everything. I think many msys programs need to be updated or configured to handle TERM=xterm-256 or anything not-cygwin correctly.

[akrieger]

More updates:

• I realized I was running in raw 'msys' mode and not 'mingw64' mode as recommended for 'daily driving'. Changing MSYSTEM=MINW64 seems to change how things work and I didn't need the TERM override anymore? It's unclear.
• I reinstalled ConEmu and MSYS2 again, on a lark, and now everything sucks again. I have terrible / nonfunctional performance in applications unless I disable ConEmu's injection, but if I do that I don't have full ansi colors in ConEmu anymore. ConEmu's msys wrapper seems to work fine (because there's no nested injection happening) but certain programs behave... poorly.
• cygwin less still requires TERM=cygwin to process up/down arrows correctly, unfortunately.

I think in general I should get off Cygwin, but I should probably dig into why less requires TERM=cygwin for arrows to work right.

[akrieger]

msys2/MSYS2-packages#1124 is the closest other issue I've managed to find about this, but nothing I've tried works except setting TERM=cygwin.

[akrieger]

Also #6045 looks topically similar. Hm.

[akrieger]

I am starting to think my issue is just that I was confused about how arrows keys are 'supposed' to work in a real terminal emulator and I was spoiled by TERM=cygwin defaulting me to some less robust input handling mode, and I need to just map arrow keys manually in the relevant apps until I either give up or get the responsiveness style I want.

[jljse]

I got similar behavior today,
and changed option of msys(from terminal window's title bar) Terminal/Type from "xterm" to "xterm-256color" fixed behavior in my case.
I've never changed TERM env by myself (echo $TERM shows "xterm-256color")
so maybe different situation from others

[akrieger]

Weird, having term be xterm-256color is what made things wonky for me (but again, that's probably because I'm used to non-xterm behavior for my command line programs).

[akrieger]

@jljse how did you change the terminal type 'from the window's title bar' exactly?

[akrieger]

msys2/MSYS2-packages#1684 might also be relevant. Still reading through that.

[jljse]

@akrieger

how did you change the terminal type 'from the window's title bar' exactly?

Right click on the window's title bar, and select 'Options...'.
but sorry, after my post, I faced same behavior again just after Windows reboot.
It's wierd as you say.

currently, I do workaround almost everyday:

1. start msys
2. right click on the window's title bar, and select 'Options...' to open popup window
3. select 'Terminal' from left menu, and close (no need to save/apply, strangely)
4. restart msys , then behavior fixed until Windows reboot

[akrieger]

What terminal emulator are you using? mintty, which comes with msys2? I'm using WT directly but running msys bash inside it.

[jljse]

ah... I misunderstand about context. I wrote about mintty (shortcut point to msys2_shell.cmd) .
I tried it on cmd and WT today. and they also act same as mintty.
Step 1~3 on mintty fix the behavior of bash on cmd and WT, too.
if it does not work for you, my case is similar but defferent from your case. Sorry not for help.