Issue when running fzf via SSH in Git Bash

[glen-84]

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable): 0.10.781.0

Any other software?

Git for Windows: 2.26.0

Steps to reproduce

1. Create a profile with the commandline: %PROGRAMFILES%/Git/bin/bash.exe -li.
2. SSH into a Debian64 machine (I'm using VirtualBox).
3. Run fzf.

Expected behavior

Proper output/rendering.

Actual behavior

When I run where ssh, there are 2 SSH binaries:

• C:\Program Files\Git\usr\bin\ssh.exe (OpenSSH_8.2p1, OpenSSL 1.1.1e 17 Mar 2020)
• C:\Windows\System32\OpenSSH\ssh.exe (OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5)

1. Using the first (which is the default), fzf is completely broken. See screenshot 1 below.
2. Using the second, fzf appears to work correctly.

Why do they differ? Is there a bug with Git for Windows' SSH binary?

• Inside the VM:
  • TERM: cygwin
  • LANG: en_ZA.UTF-8
  • LC_ALL: ``

[DHowett-MSFT]

If you set TERM to xterm-256color before running fzf, does it work better? (I imagine it doesn’t.)

Even so- Cygwin, before version 3.1 (which git for Windows hasn’t yet updated to), thinks it’s smarter than the windows console and translates all incoming VT sequences back into Win32 API calls. It doesn’t do a very good job of this.

The problem is, conhost has been able to parse VT for the better part of five years now.

Win32-OpenSSH has no such translation.

Closing as external in the meantime :)

[glen-84]

If you set TERM to xterm-256color before running fzf, does it work better? (I imagine it doesn’t.)

It behaves differently, but it's still broken.

Even so- Cygwin, before version 3.1 (which git for Windows hasn’t yet updated to) ...

Thanks for the explanation. So do you think that this is likely to be fixed when Cygwin is updated?