No keyboard input on latest ble.sh commit

[teutat3s]

ble version: (cannot execute because of no input, but would look like this)

❯ echo "$BLE_VERSION"
0.4.0-devel4+75c4a84

Bash version:

❯ ble/widget/display-shell-version
GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu) [NixOS 24.05 (Uakari)]
ble.sh, version 0.4.0-devel4+70a325f (noarch) [git 2.44.1, GNU Make 4.4.1, GNU Awk 5.2.2, API 3.2, PMA Avon 8-g1]
bash-completion, version 2.13.0 (hash:480ffcc6a751e55621ec526eb5dea7a0d86d9e72, 17877 bytes) (noarch)
fzf key-bindings, (hash:a789b19de9ea0e6dd21dd3f35e36c4b9710d73a8, 5488 bytes) (noarch)
WARNING: fzf integration "integration/fzf-key-bindings" is not activated.
starship, version 1.19.0 (rustc 1.77.2 (25ef9e3d8 2024-04-09) (built from a source tarball), 1980-01-01 00:00:00 +00:00)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=15.1-west/15.1-2+ri, alacritty:2300 (0;2300;1)

After updating from 0.4.0-devel4+70a325f to the latest ble.sh commit on master, I cannot type in my shell anymore. Even pressing keys like Enter or CTRL-c is without effect. I would really like to debug this.

EDIT: To rule out alacritty as the culprit, I reproduced the issue with foot terminal as well.
EDIT2: If it helps, I can start a git bisect to close in on a commit that might have introduced this.
EDIT3: The last good commit I was able to test is 63be48d. I suspect 48c7bbe might have introduced something that breaks my setup.

[akinomyoga]

Thank you for the report. Thank you also for identifying the commit. However, I cannot reproduce the problem.

• Q1: Could you check if the problem reproduces (with the latest commit 75c4a84 but not with the culprit commit 48c7bbe) with the minimal Bash configuration?

$ cp ~/.bash_history ~/.bash_history.backup20240821 # Please back up your shell command history
$ INPUTRC=/dev/null bash --noprofile --norc
$ source /path/to/ble.sh --norc
<--- Does the problem reproduce here?
$ exit
$ cp ~/.bash_history.backup20240821 ~/.bash_history # recover the history

[teutat3s]

Thanks for the quick response. I'm getting conflicts when trying to back out the culprit commit, so this might take a little longer.

[teutat3s]

I was able to resolve the conflicts (not sure if I broke anything else in the process).

• Q1: The problem does not reproduce in my fork without the culprit commit 48c7bbe.

EDIT: I am able to reproduce the problem with the minimal Bash configuration on your latest master branch commit 75c4a84.

[akinomyoga]

• Q2: When you input something do you see any error messages?

I don't have an idea, but maybe the cache is not updated.

• Q3: Does the problem reproduce with 75c4a84 when the cache is cleared?

$ cp ~/.bash_history ~/.bash_history.backup20240821
$ INPUTRC=/dev/null bash --noprofile --norc
$ date
<-- What is the time?
$ bash /path/to/ble.sh --clear-cache; source /path/to/ble.sh --norc; ls -la "$_ble_base_cache"
<-- What is the output of `ls -la "$_ble_base_cache"` here?
<-- Does the problem reproduce?
$ exit
$ cp ~/.bash_history.backup20240821 ~/.bash_history

I'm not sure if the reported behavior is actually related to the cache, but the cache is supposed to be updated when the corresponding file (the main file ble.sh or other script files depending on the cache file) is updated. The comparison is based on the time stamp of the files, so if the filesystem where the cache directory is located doesn't offer normal support for the time stamp, the cache can be left outdated, which can cause issues with the user input. Or if the cache directory is marked as readonly and if any attempt of changes to the cache directory would be discarded, issues happen. Or if you have multiple working trees of the ble.sh repositories (for ble.sh v0.4), the version differences of the cache between those working trees can cause issues.