reverse-i-search shows escape sequence

[glhez]

Hello,

Whenever I use the reverse-i-search (Ctrl R) under git-bash, git-cmd (eg: git-cmd.exe --command=usr/bin/bash.exe -l -i) or under ConEmu, I have the following problem:

As you can see, when I type left/right/up/down key, the search display [D[A[C[B.
This can be rather nasty when you search for a long command and type enter - in best case, it fails.

This was working fine with msysgit.
I'll try to test it with MSYS2 official package.

Detailed image are also here as a set of PNG image: https://bitbucket.org/glhez/zeta-bash/downloads/git_issue_revsearch.7z

[dscho]

@glhez try to set the TERM environment variable to xterm:

export TERM=xterm

and see whether that fixes it for you.

[glhez]

Does not change anything in ConEmu and git-cmd. I tried it also in bashrc.

And I forgot to tell that I use Clink v0.4.4 [git:a60c0a].

[dscho]

I have no idea what Clink is. But when I call

> bash --login -i

in Git CMD and then call

export TERM=xterm

the cursor keys end the reverse search, as intended... So I have no idea what is going on on your side.

[glhez]

First, sorry, now that I reread myself, I see that I did not put the versions of software used (Windows 7, git 2.5.1 x64, ConEmuC build 150821 x64).
Second, clink provide the same thing than Bash, but using poor old cmd.

Now onto my problem:

The cursor keys end the reverse search, as intended yes, it does. But it does not send the \e (or whatever), and only left the [D. If I do that (with/without TERM=xterm):

$ echo -e 'bP\e[Da'
ba

The 'a' move to the position of the P.

It is more like the rev-search handler does not print the \e before printing the [D escape sequence.
While holding the Ctrl key, I have also [1;5D.

[dscho]

Second, clink provide the same thing than Bash, but using poor old cmd.

Is this not more of a clink problem than Git for Windows'?

First, sorry, now that I reread myself, I see that I did not put the versions of software used (Windows 7, git 2.5.1 x64, ConEmuC build 150821 x64).

Given that Clink provides "Powerful Bash-style command line editing for cmd.exe", several other crucial bits of information are missing: what options were chosen in the installer (Use Git from Bash only? Use Git from the Windows Command Prompt?)? Why do you run Clink from Git Bash? Could you provide a concise, comprehensible list of steps to reproduce your problem quickly and easily (what we call an "MCVE", a Minimal, Complete and Verifiable Example?

[glhez]

I'll try removing clink, conemu, git-for-windows, reboot, reinstall git-for-windows, remove .bashrc, start command line, but for now:

• Installation using Use Git from Bash
• clink is loaded in cmd.exe, but I don't know (I don't have enough technical knowledge to tell) if it is loaded when I use git-cmd.exe from the Execute (Win R) like this: "<path .. to>\git-cmd.exe" --cd="D:\sitidev" --command=usr/bin/bash.exe -l -i.

[dscho]

clink is loaded in cmd.exe, but I don't know (I don't have enough technical knowledge to tell) if it is loaded when I use git-cmd.exe from the Execute (Win R) like this: "<path .. to>\git-cmd.exe" --cd="D:\sitidev" --command=usr/bin/bash.exe -l -i.

Can't you find out using the Process Explorer, or at least the Task Manager?

[glhez]

I retested:

1. Windows 7 x64 French, SP1
2. Removed clink 0.4.5
3. Removed ConEmu 150821
4. Removed git-for-windows 2.5.1 x64
5. Checked for remnant of those process
6. Rebooted
7. Moved .bash_profile, .bashrc out of %USERPROFILE%
8. Installed git-for-windows 2.5.1 as Administrator (my user account is not an admin one). All options are default, shown in this:
   
9. Using Git Bash contextual option, which launch mintty: no problem, TERM=xterm-256color.
10. Using Git Cmd running this command: "C:\Program Files\Git\git-cmd.exe" --cd=E:\git --command=usr/bin/bash.exe -l -i FAIL
11. Same, but with export TERM=xterm: FAIL
12. Same, but with export TERM=xterm-256color: FAIL
13. Putting the export TERM=xterm in ~/.bash_profile (which is empty): FAIL
14. Putting the export TERM=xterm-256color in ~/.bash_profile (which is empty): FAIL

ConEmu and Clink are out of the way, they are not responsible - loaded or not.

And I'm back with my initial question: is there a way to put bash in debug, that is to print out in a file anything that would be output by bash (or readline?)? (looking on google for that only give me answer on how to debug scripts).
I would be able to tell if bash really send a \e along the [D, a

By the way, here is the display while using vim:

And to be exhaustive, the settings on the default console program:

As well as a dump of env: https://gist.github.com/glhez/fcc63aee324f18048691#file-env-list

[dscho]

Thank you for this easy-to-follow reproduction recipe.

When I call

"C:\Program Files\Git\git-cmd.exe" --command=usr/bin/bash.exe -l -I

in Windows 10, this happens to me, too: I search backwards (note: I have to type at least one character first), then I hit any of the cursor keys and am greated with [A (... [D).

The reason is that the cursor keys send an Escape sequence, e.g. Cursor Up sends \e[A, and that Escape character (\e) is interpreted by the shell as "stop the search". The shell would interpret the \e[A as "Cursor Up", too, but the Escape character was already consumed, hence only [A are left, and interpreted literally.

So after some digging through Bash history and readline configuration, it appears that adding these lines to your /etc/inputrc might fix things (you need to restart the Bash after inserting the lines, of course):

  "\e[A": previous-history # Cursor Up
  "\e[B": next-history     # Cursor Down
  "\e[C": forward-char     # Cursor Right
  "\e[D": backward-char    # Cursor Left

Of course, ideally these lines would be guarded between $if term=cygwin ... $endif, but that did not work for me. Maybe you can dig deeper?

[dscho]

Actually, I take it back. I just re-tested with $if term=Cygwin ... $endif and it works as expected. Please confirm.

[glhez]

I installed Git for Windows 2.5.2 x64, but it does not work for me.

Also, in reverse-i-search mode, I noticed that Ctrl + Arrow fails too: Ctrl + Right -> [1;5C
And this shortcut is already in the inputrc file.

[dscho]

Hmm. For me, it also does not work any longer. Which is a bummer because it really worked at some stage.

So let's reopen the issue.

At this point, I cannot invest any more time into trying to find a solution, though, so I would recommend diving into the details of readline and the inputrc file.

[glhez]

I tried to use msys2 since gfw is based on, and following this link to run msys2, the same problem occurs.
But it was not in msysgit, so perhaps there was a patch that avoided this. I'll try to get in touch with Msys2 team.

[dscho]

@glhez so you're trying to avoid studying the readline and inputrc documentation? :blinking:

[glhez]

The documentation of readline gives me isearch-terminators which default to ESC or Ctrl J. So, I tried with set isearch-terminators "C+J" with no noticeable effects.

Then I tried this set isearch-terminators "P" in inputrc. And also, bind -x '"\e[D": echo "Left Arrow"' (in bash, I did not find a way to put in inputrc; must be an extension).

Typing Left arrow works fine: the console display "Left Arrow". Now, typing left in the rev-search, still print [D.

1. The keybinding works only when not rev-searching.
2. The terminator works, if you tape "P" while rev-i-searching, it stops it.
3. With the isearch-terminators set to P, mintty also exhibit the same behaviour.

[dscho]

So, I tried with set isearch-terminators "C+J" with no noticeable effects.

Did you not rather want to set isearch-terminators to "\e[A \e[B \e[C \e[D \e C-J"?

[glhez]

Tested.... and only the first "\e[A" remains (see bind -v | grep isearch-terminators).
I tried with \e[D (right) to see, still [D. Even with \e[A, I have the same behaviour.

And testing with P was to see if was doing something: either the ESC is hard-wired into the code, either the ESC is catched beforehand. And Ctrl J also seems to be hard-wired.

[yoshiwaan]

Just to make this more annoying, I think the reason you might have thought this worked @dscho is because this behaviour doesn't happen every time. I'll run the same few reverse searches over and over and press the same arrow keys and get the escape character sometimes and not others.

This happens with vanilla Msys2 (i.e. not Git for Window's flavour) using a windows terminal emulator like ConsoleZ or the default when you just run bash.exe, but not with the mintty.exe that comes with Msys2.

I've tried importing all the environment variables in a consolez shell into the mintty session and ensured that all my profile files are the same as /etc/skel in both emulators and it's the same. Mintty works but the windows emulator doesn't.

[yoshiwaan]

FYI:
https://sourceforge.net/p/msys2/tickets/243/
https://sourceforge.net/p/msys2/tickets/244/

[dscho]

@yoshiwaan nice find! It never occurred to me that the key press duration might have anything to do with it. That's why things seemed to be fixed, and then broken again!

[glhez]

Thanks @yoshiwaan !
I tried to key press as fast as possible, and it works... But then again, it means I have < 0.1ms to press Left/Right. Thus, this annoying behavior also targets Windows 7

[dscho]

I guess we can safely close this ticket now, as we tried everything in our power to fix this, right?

[glhez]

Better yet: I no longer have the problem (and I can't seem to reproduce it as easily as before) and ConEmu/git bash were updated:

git 2.5.1 x64 -> git version 2.11.1.windows.1
ConEmuC build 150821 x64 -> ConEmuC build 170118