xterm tab key (temporarily) locks keyboard

[Adam Dinwoodie]

On Sun, 18 Oct 2020 at 19:23, Brian Inglis wrote:
>
> On 2020-10-18 12:07, Frank Eske via Cygwin wrote:
> > If the tab key is entered as the first character running the bash shell on
> > an xterm terminal, the keyboard temporarily locks. Control-C writes ^C but
> > doesn't unlock it. This doesn't happen on Fedora. It also doesn't lock if a
> > space is typed first.
> >
> > This occurs whether or not the xterm console is in an X environment.
> >
> > For some reason I seem to accidentally do this a lot more often than I'd
> > like, so it's a real nuisance. I checked this mailing list for the last
> > four months and couldn't find " tab" or a useful "tab ", I find it
> > difficult to believe that I'm the first to see this, so maybe there's
> > something I changed that's making this happen. Any advice on what that
> > might be?
>
> Bash command completion is searching for commands to display - you will
> eventually get asked if you want to "Display all 4587 possibilities? (y or n)"
> (or similar number) after it has loaded all executable names from all
> directories in your PATH!

There are a few things that can make this particularly painful:

- Your Cygwin environment inheriting a large PATH from Windows, so it
needs to search through a lot of directories.

- The PATH containing network shares, especially if some of those
network shares are relatively slow.

You can check what's currently in your PATH by just running `echo
$PATH`. There's lots of different ways of resolving this, but probably
the easiest is to reset your PATH by adding something like `export
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin` to
your ~/.bashrc file.