Git Bash hangs on CTRL + I [closed]

Question

When I am running Git Bash, I occasionally accidentally press CTRL+I and this freezes up the terminal for quite a long time, before releasing.

I have tried CTRL+D, CTRL+Q, CTRL+C thereafter, but to no avail.

My only options at present are to simply wait or to forcefully close the Git Bash window. Neither of which are acceptable.

Does anyone know what CTRL+I is doing? And is there an easy way to cancel it after accidentally pressing it?

Careaga

CTRL I is tab, IIRC. – Zulazulch

does ctrl-\ work perhaps? – Kami

I see the same when using Ctrl+R to search through recent commands. Once the entry I want is found, Enter excutes it. Via muscle memory from IDEs I press Tab to 'complete' it, which then freezes up for a long time. – Joktan

Not sure why this was closed as a question, as it relates to Git Bash, which is a software tool used by programmers, as per the closure description. – Careaga

Answer 1

As wildplasser said in a comment, CTRL+I is the same as TAB. In bash, the tab key invokes the tab completion code, which searches around to see what words fit with whatever you have typed so far. On Unix-y systems this is generally pretty fast. Apparently it's horribly slow on your system. You might be able to speed it up, but if all else fails, you can just disable it.

See also git bash auto complete slow on windows 7 x64, https://blog.entelect.co.za/view/7554/speed-up-git-bash-on-windows, and https://superuser.com/questions/421397/disable-bashs-programmable-autocompletion-based-on-command.

Dysthymia

Tab completion is programmable. It's likely that hitting Tab at that particular point invoked some search code that took a very long time to execute. A simple case might be when the shell expects a file name and you it Tab while in a directory containing a huge number of files. More likely, it might be invoking some git command that happens to take a very long time. (You could have the same symptom on a UNIX-like system if tab completion happens to invoke some very slow command.) – Renowned

@KeithThompson: Yes; the last link is about disabling it in general, while the first two links are concerned with making the Git-specific completions go faster on Windows 7 (may or may not apply to Windows 10; I don't know, I don't do Windows...). – Dysthymia

@Dysthymia Yes, this is Git Bash on Windows (8). Thanks. This helps a great deal. – Careaga

Answer 2

Cause

I had the same problem: Ctrl+I or Tab Tab on an empty input line in Git Bash on Windows was taking up to 7 seconds before showing Display all 5413 possibilities? (y or n) and Ctrl+C was not stopping the search ... very frustrating because I frequently enter Tab Tab inadvertently.

This behavior was happening both inside and outside Git repositories.

This is due to the command completion action being slow on Git Bash (possibly because of a slower Windows filesystem ?).

Solution

Add this line to ~/.bashrc :

complete -Ef # fix slow empty line autocompletion in Git Bash

-E configures the completion on empty line and -f sets the action to file (list the files in the current directory).

And if you never want empty line completion (e.g. if it only happens inadvertently) you can use complete -E instead.

See Bash manual on Programmable Completion Builtins for more documentation.

I got help from this answer

Eventide