[bash-completion] Prompt hangs after starting to write scp directory

[iantra]

Versions of everything: GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) ble.sh, version 0.4.0-devel3+d340233 (noarch) bash-completion, version 2.10 (hash:b6da7f7edfc1c3c5196c86c81fb05fce96f83c03, 74550 bytes) (noarch) bash-preexec, (hash:5f1208c33e624859eea70e3843bd9b8c9a06819e, 13046 bytes) (noarch) (integration: on) bash-it, version +35334cdc (noarch), alias(general), completion(aliases bash-it system), plugin(autojump base blesh fzf) locale: LANG=en_US.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_COLLATE=C LC_IDENTIFICATION=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 terminal: TERM=xterm-256color wcwidth=14.0-musl/14.0-2+ri, xterm:115 (1;115;0)

Started using ble.sh recently, really love being able to have zsh/fish-style suggestions and syntax highlighting while still using bash. Great project, thank you so much for putting this all together! So far, this is the only problem I've encountered, but it is a pretty annoying problem.

When typing out an scp command, the whole prompt hangs after trying to input a directory. Anything typed after : will not show up for several minutes, after which the prompt becomes responsive again. Using the autocomplete suggestion from history and swapping only the directory seems to work mostly ok. However, in both cases the prompt also gets quite sluggish while typing the directory, with some key presses taking a few seconds to register.

Since I'm running bash-it with a few plugins and whatnot enabled I thought it might be a compatibility issue with that, but I've tried disabling other stuff (particularly fzf as I've seen other issues mentioning problems with that) to no avail.

It happens both when attempting to copy to and from a remote location, but seems to be different for different IP addresses, with some hanging for only a short time and some much longer. I suspect the problem might be some sort of network or history based suggestion attempt gone awry, but don't know enough about the inner workings of the program to say for sure.

[akinomyoga]

Thank you for the report. I guess this is caused by bash-completion's _scp_remote_files. Does the behavior change after overwriting the function by running the following commands?

$ __load_completion scp
$ _ssh_scp_remote_files() { true; }

If so, I'll later consider how to work around it.

[iantra]

Running those commands doesn't seem to change anything, although I just now realized that disabling ble.sh and just trying tab completion yields the same results. So, I guess it's not an issue with this program after all ¯_(ツ)_/¯. It seems ble.sh was only making it more obvious by running the completion continuously as I typed. Still, some sort of timeout or override if completions are taking too long (or even running them in a separate thread?) might be a nice idea for a new feature to keep the prompt chugging along smoothly, although maybe a bit out of scope.

Thanks for the help anyway, I'll do some more investigating on my side and see if I can figure out the real root of the issue.

[akinomyoga]

Hmm, OK.

Ah, wait! I'm really sorry, there was a typo in the above commands. It's _scp_remote_files but not _ssh_scp_remote_files. Could you try them again with _ssh_scp_remote_files replaced by _scp_remote_files?

$ __load_completion scp
$ _scp_remote_files() { true; }

[iantra]

That worked! I guess adding those two lines to my bashrc is the easiest way to patch this for now, thanks. I still think some sort of timeout or async operation would be good for UX in case some other completions bug out... Might try my hand at doing something like that whenever I have some free time.

[akinomyoga]

I still think some sort of timeout or async operation would be good for UX in case some other completions bug out...

Yeah, actually that is what I'm thinking for the workaround. Let me keep this issue open until I add the workaround later. I'll probably find time tomorrow.

[akinomyoga]

I found the time so added a workaround in commit a4a779e45d4a8b1037ed49fb5953db94b07e5715. Could you see if the situation is improved by the latest master branch in your environment (without the tentative fix in your bashrc)? You can update ble.sh by running ble-update.

[iantra]

The update seems to have fixed it! Just out of curiosity, I had a look at the commit and it seems that you are killing the ssh (and dnf) completion functions when they run. Wouldn't this mean that the completions now won't work at all, even for people who didn't have issues with it before?

[akinomyoga]

Thank you for checking!

it seems that you are killing the ssh (and dnf) completion functions when they run.

ssh and dnf completion (and their child processes) are conditionally killed when unprocessed user input is arrived in stdin (which is judged by a repeatedly called shell function ble/complete/check-cancel). This is controlled by the shell function ble/util/conditional-sync. I have once explained the usage of ble/util/conditional-sync here.

Do you have any problem with it? In my environment, it seems to complete the remote files as before unless I continue to type additional characters.

[iantra]

Thanks for the link and the wonderful explanation, I get it now. I don't have any problems, but I never used scp autocomplete in the first place. I worried it might cause issues for other people, but I was just misunderstanding the code.

[akinomyoga]

OK! Thank you for your comment! If everything is fine, you can close the issue!