Bash prompt misbehaves when used from a vim terminal buffer

[bobrippling]

• I was not able to find an open or closed issue matching what I'm seeing

Possibly related issues:

• MinTTY issues (characters, Ctrl+C, etc. get eaten or messed up) #2239
• Why does my [Escape] binding in inputrc have a delay? #3282

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.33.0.windows.1
cpu: x86_64
built from commit: fb59c1de9fd599a3eeb8459eb7cab731c6672ea3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19042.1415]

• What options did you set as part of the installation? Or did you choose the defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Core
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

• Any other interesting things about your environment that might be related to the issue you're seeing?

No - I believe this can be reproduced from a vanilla setup.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a Minimal, Complete, and Verifiable example this will help us understand the issue.

vim -u NONE
:terminal
# You'll be presented with a bash prompt from a terminal buffer inside vim.
# In here, enter the following text very quickly: `a && b` (the spaces are crucial).

• What did you expect to occur after running these commands?

The text a && b should be ready at the bash prompt

• What actually happened instead?

The text a &&;2ub appeared at the bash prompt - I suspect something like the & is being interpreted as an escape code due to the odd terminal setup between vim and bash in the gitbash terminal.

• If the problem was occurring with a specific repository, can you provide the URL to that repository to help us with testing?

<n/a>

Investigation

I've found the issue wasn't present in older versions and believe the first affected version to be 2.25.0:

Git-2.23.0-64-bit.exe ok
Git-2.24.0-64-bit.exe ok
Git-2.25.0-64-bit.exe bug present
Git-2.25.1-64-bit.exe bug present
Git-2.26.0-64-bit.exe bug present
Git-2.33.0-64-bit.exe bug present

[dscho]

git version 2.33.0.windows.1

This version came with a different MSYS2 runtime version than v2.35.0. Could you try with the current version?

Also, you may want to enable support for pseudo consoles in the installer, that will most likely make a difference.

[bobrippling]

Sure, I'll give that a whirl, should be back on that machine in the next few days. I'll try pseudo console support too, thanks for the suggestion.

[bobrippling]

Thanks for your help. I reproduced the issue with Git-2.35.1-64-bit. This was with:

• MinTTY as a terminal
• Enabled experimental support for pseudo consoles

The same issue occurs with winpty bash (inside a vim terminal only).

Is there anything I can do to use the pseudo consoles, or do they get picked up automatically? And are there any other steps that might help diagnose?

[dscho]

@bobrippling could you please test the latest snapshot, there are a couple of fixes that might address your issue.

[bobrippling]

Sure - should be able to check it out in the next few days

[bobrippling]

@dscho thanks for the update. I've found the bug present like so:

• Bug present Git-prerelease-2.35.1.windows.2-4-gbfc55a2345-20220215094111-64-bit
• Bug present Git-prerelease-2.35.1.windows.2-7-g158a30d60b-20220224121117-64-bit

[dscho]

@dscho thanks for the update. I've found the bug present like so:

* Bug present `Git-prerelease-2.35.1.windows.2-4-gbfc55a2345-20220215094111-64-bit`

* Bug present `Git-prerelease-2.35.1.windows.2-7-g158a30d60b-20220224121117-64-bit`

And which is the oldest snapshot that has the bug?

[bobrippling]

Gave these a test:

• ✔️ Git-prerelease-2.24.0.windows.1.4.g02af2cc5bf-64-bit no bug (Wed, 6 Nov 2019 10:24:11 +0100)
• ❌ Git-prerelease-2.24.0.windows.2.10.ga4c71cf243-64-bit bug present (Sat, 16 Nov 2019 00:47:52 +0100)

So I would guess the bug is in this range of commits, but there doesn't seem to be anything tty related.

[dscho]

• ✔️ Git-prerelease-2.24.0.windows.1.4.g02af2cc5bf-64-bit no bug (Wed, 6 Nov 2019 10:24:11 +0100)

  • ❌ Git-prerelease-2.24.0.windows.2.10.ga4c71cf243-64-bit bug present (Sat, 16 Nov 2019 00:47:52 +0100)

So I would guess the bug is in this range of commits, but there doesn't seem to be anything tty related.

It is more likely that the bug is in the msys2-runtime component.

Can you run a diff on the etc/package-versions.txt files of those two snapshots (those files are also contained in the PortableGit editions, which are self-extracting 7-Zip files, read: you can open them in 7-Zip to extract just the desired files).

[KSR-Yasuda]

• What did you expect to occur after running these commands?

The text a && b should be ready at the bash prompt

• What actually happened instead?

The text a &&;2ub appeared at the bash prompt

Don't you push Shift + Space there, and the keys turn to ;2u?

If so, how about adding below into your .vimrc?

silent! tnoremap <S-space> <space>

I think this problem has existed since quite before ver. of git-for-windows env.
I had also worried about this problem before, and applied the first aid.

[bobrippling]

Can you run a diff on the etc/package-versions.txt files of those two snapshots (those files are also contained in the PortableGit editions, which are self-extracting 7-Zip files, read: you can open them in 7-Zip to extract just the desired files).

Ah thanks! Looks like it could be the vim change between v8.1.2104..v8.1.2292, which stands out below.

`etc/package-versions.txt` diff

--- PortableGit-02af2/etc/package-versions.txt 2019-11-06 11:55:04.000000000 +0100
+++ PortableGit-a4c71/etc/package-versions.txt 2019-11-17 12:29:43.000000000 +0100
@@ -4,3 +4,3 @@
 bzip2 1.0.8-1
-ca-certificates 20180409-1
+ca-certificates 20190110-1
 coreutils 8.31-1
@@ -15,3 +15,3 @@
 gettext 0.19.8.1-1
-git-extra 1.1.423.4f345a3-1
+git-extra 1.1.440.61ea095-1
 git-flow 1.12.3-1
@@ -29,4 +29,4 @@
 libcrypt 2.1-2
-libcurl 7.66.0-1
-libedit 20190324_3.1-1
+libcurl 7.67.0-1
+libedit 20191025_3.1-1
 libexpat 2.2.9-1
@@ -64,6 +64,6 @@
 mingw-w64-x86_64-bzip2 1.0.8-1
-mingw-w64-x86_64-ca-certificates 20180409-5
+mingw-w64-x86_64-ca-certificates 20190110-1
 mingw-w64-x86_64-c-ares 1.15.0-1
 mingw-w64-x86_64-connect 1.105-1
-mingw-w64-x86_64-curl 7.66.0-1
+mingw-w64-x86_64-curl 7.67.0-1
 mingw-w64-x86_64-expat 2.2.9-1
@@ -71,5 +71,5 @@
 mingw-w64-x86_64-gettext 0.19.8.1-8
-mingw-w64-x86_64-git 2.24.0.windows.1.4.g02af2cc5bf-1
+mingw-w64-x86_64-git 2.24.0.windows.2.10.ga4c71cf243-1
 mingw-w64-x86_64-git-credential-manager 1.20.0-1
-mingw-w64-x86_64-git-doc-html 2.24.0.windows.1.4.g02af2cc5bf-1
+mingw-w64-x86_64-git-doc-html 2.24.0.windows.2.10.ga4c71cf243-1
 mingw-w64-x86_64-git-lfs 2.9.0-1
@@ -88,3 +88,3 @@
 mingw-w64-x86_64-libunistring 0.9.10-1
-mingw-w64-x86_64-libwinpthread-git 7.0.0.5544.15da3ce2-1
+mingw-w64-x86_64-libwinpthread-git 8.0.0.5574.33e5a2ac-1
 mingw-w64-x86_64-libzip 1.5.2-2
@@ -106,3 +106,3 @@
 msys2-runtime 3.0.7-3
-nano 4.4-1
+nano 4.5-1
 ncurses 6.1.20190615-1
@@ -121,3 +121,3 @@
 perl-HTML-Tagset 3.20-2
-perl-HTTP-Cookies 6.04-1
+perl-HTTP-Cookies 6.05-1
 perl-HTTP-Daemon 6.01-2
@@ -129,3 +129,3 @@
 perl-JSON 2.97001-1
-perl-libwww 6.39-1
+perl-libwww 6.41-1
 perl-LWP-MediaTypes 6.02-2
@@ -148,3 +148,3 @@
 unzip 6.0-2
-vim 8.1.2104-1
+vim 8.1.2292-1
 which 2.21-2

If so, how about adding below into your .vimrc?

silent! tnoremap <S-space> <space>

This fixes it for me, thanks!
To give more detail, I've not seen the problem on my local machine (Linux/X11), and this occurs over a remote desktop connection, so I guess the shift-key release was delayed and exposing this problem. Oddly, I can't reproduce this on my machine by manually entering & & <shift-space>. Managed to reproduce (with a slightly different outcome) inside gvim. Had a search and this must be vim/vim#6040.

So this is a vim bug - sorry for the noise, and thanks again for all your help @dscho, it's appreciated.

And thanks for the tip off @KSR-Yasuda - had this problem for about a year now!