Auto-completing path ending with & causes prompt to hang

[strarsis]

Windows Build Number

Microsoft Windows [Version 10.0.19043.985]

WSL Version

• WSL 2
• WSL 1

Kernel Version

Linux version 5.4.72-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Oct 28 23:40:43 UTC 2020

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

1. Enter a path into bash prompt that ends with an ampersand (&), the path doesn't have to exist (e.g. /test/&), the issue occurs with non-existing and existing paths alike.
2. Hit tab for autocompletion of path.
   Note that the prompt is now frozen, no shurtcut can bring back the prompt (like Ctrl + c or Ctrl + z).
   After a significant amount of time the prompt seems to reset while showing an error (because of the ampersand).

-bash: d: command not found

One real life example is navigating to a folder that contains an ampersand (nothing unusual, like the name of a company).

Expected Behavior

Auto-completion should work fine (or skip when path doesn't exist).

Actual Behavior

Prompt hangs for a significant amount of time and can't be reset.

Diagnostic Logs

No response

[rescenic]

& is bash operator. if you want, create folder with '&'.

Learn more here: https://linuxhint.com/bash_operator_examples/#o21

[strarsis]

You are right. But what if you just want to autocomplete a path ending with &?

Can you reproduce this issue?
Enter a path (doesn't have to actually exist) ending with & and hit Tab for autocompletion.
For me in Ubuntu 20.x default bash the whole terminal hangs for a long time and with no way resetting it.

[rescenic]

Just type in cmd.exe: wsl --shutdown , then launch again Ubuntu distro.
Simple way to solve your problem, just rename that folder or use ZSH shell.
It's same for Windows.

[therealkenc]

I was able to reproduce here, but wasn't curious enough to look what bash completion is up to specifically under strace(1). This is a variation /dupe #4234 or #5696 (others). Whatever bash is doing, it is doing it faithfully, but slowly. Which is #4197. Prompt returns reasonably with $PATH absent all the /mnt/c entries. The prompt did return for me eventually with a really fast ssd and all the Windows paths.

FWIW, it isn't really all that fair to punt these ultimately cause #4197. It just isn't a particularly contemplated scenario on Real Linux™ to have two dozen (or more) paths to a slow network drive. You'd get the same behavior on a native box if that were a thing. Even if the /mnt/c performance on WSL2 improved by an order of magnitude, the OP repro would still be "slow" by design. Maybe there is a way to coerce bash_completion to skip certain paths (never looked into it). Or if there isn't, maybe such a thing could be invented. Worthy enough discussion to explore that much some more.

Tab after the ampersand below...

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!