[bash-completion, command_not_found_handle] gcc autoreplace terminal bricking

[wisnoskij]

ble version: 0.4.0-devel3+11aa4ab
Bash version: 5.1.16(1)-release (x86_64-redhat-linux-gnu)

Fedora 36, Kitty

Found this really weirdly specific issue where ble.sh seems to be bricking my terminal instance when typing gcc [a-Z].

As soon as a single [a-Z] character is typed after gcc (note their can be multiple dashes in between), some text in inserted and the terminal no longer accepts any input, even <C-c> does nothing.

Expected result:
gcc --help<enter>

My result:
gcc --hInstall package 'f2c' to provide command 'f77'? [N/y] <terminal no longer accepting any input>

[wisnoskij]

Note: I guess the title should read "auto-insert", it does not replace anything, it simply adds text.

[akinomyoga]

Thank you for the report! This problem has been reported at #192, but the OP has closed the issue before we identify the cause. At that time, I suspected the command_not_found hook, but it turned out that command_not_found is not set in the environment of the OP of #192.

First, I'd like to confirm that the situation is the same as in #192. Could you also check the following points?

Quoted from #192 (comment)

• Could you provide me with the result of pressing Ctrl+x Ctrl+v?
• What would be the result of the following commands?

$ complete -p gcc
$ type command_not_found

Next, to reproduce it in my environment, I would like to know the detailed code path that these hooks are called.

• Q3 Could you provide us with the xtrace log for the situation where the problem arises? The xtrace log can be obtained by the following steps:

$ bleopt debug_xtrace=blesh-xtrace.txt          # <-- This starts the xtrace logging.
                                                #      This will create a text file in the current directory
$ gcc --hInstall package 'f2c' to provide command 'f77'? [N/y]      # <-- Reproduce the problem

Then, kill the Bash session and pick up the log file blesh-xtrace.txt. Could you attach the log file?

[wisnoskij]

Ctrl+c Ctrl+v
GNU bash, version 5.1.16(1)-release (x86_64-redhat-linux-gnu) ble.sh, version 0.4.0-devel3+11aa4ab (noarch) bash-completion, version 2.11 (hash:1a7f5634b4c9816716b69a7824e0b51cfde2bca3, 76332 bytes) (noarch) starship, version 1.2.1 (rustc 1.58.1 (Fedora 1.58.1-1.fc36), 2022-02-06 00:00:00 +00:00) locale: LANG=en_CA.UTF-8 LC_COLLATE=C terminal: TERM=xterm-kitty wcwidth=14.0-west/14.0-2+ri, kitty:0 (1;4000;25)

> complete -p gcc bash: complete: gcc: no completion specification [ble: exit 1]

> type command_not_found bash: type: command_not_found: not found [ble: exit 1]

[wisnoskij]

blesh-xtrace.txt
Are +'s being used as some sort of whitespace? weird.

[akinomyoga]

Thank you! The situation seems to be the same as #192.

blesh-xtrace.txt

I've checked it. I think the following lines are closely related. f77 --version is found in completions/gcc in bash-completion.

++++ f77 --version
++++ local runcnf=1
++++ local retval=127
++++ [[ himxBHs == *\i* ]]
++++ [[ ! -S /run/dbus/system_bus_socket ]]
++++ [[ ! -x /usr/libexec/packagekitd ]]
++++ [[ -n '' ]]
++++ [[ ! -x /usr/libexec/pk-command-not-found ]]

It seems that command_not_found seems to be invoked even though it is not set. Oh, sorry, I was thinking it is command_not_found but the name was actually command_not_found_handle.

• Q4: Could you check the result of the following command?

$ type command_not_found_handle

Anyway, now the problem seems to be that command_not_found_handle is called in the middle of auto-complete and trying to read inputs from stdout. I'll later think about a workaround for command_not_found_handle. [ I'd generally like the general solution that covers all the similar problems, but there is some dilemma that the user inputs should not be stolen by completers in auto-complete while some completers require user inputs to terminate it. I think there is no general solution after all. ]

[wisnoskij]

$ type command_not_found_handle
log.txt

But it's even more complicated than that, right? it is running f77 --version, and then outputs the result. Why would you ever try to run a potential auto-complete suggestion?

Is Ble.sh trying to pre-run code as I am typing it? That is why this is gcc specific, as gcc takes code as an input?

[akinomyoga]

$ type command_not_found_handle
log.txt

Thanks! It is exactly what we see in the xtrace log. So this must be the interference with command_not_found_handle set by fc36, bash_completion, and ble.sh.

But it's even more complicated than that, right? it is running f77 --version, and then outputs the result. Why would you ever try to run a potential auto-complete suggestion?

No, it's not running the suggestion. As I have already pointed out, f77 --version is not a suggestion but used by another bash configuration bash-completion loaded in your environment (probably from /etc/profile.d/bash_completion.sh). In short, it is configured by your system outside ble.sh, and f77 --version is the command used therein to generate or determine the suggestions but not the resulting suggestion.

Is Ble.sh trying to pre-run code as I am typing it?

No.

That is why this is gcc specific, as gcc takes code as an input?

No. The reason that it seems to be gcc-specific is just that the completion is implemented for each specific command in bash-completion.

Are +'s being used as some sort of whitespace? weird.

This is just from your PS4 setting. You can find the description of PS4 in §5.2 of Bash Manual.

[wisnoskij]

Oh, I see. Sorry for the not following you the first time.
I see the problem. Their is not really any easy console way to even try to fix missing dependencies in the middle of typing a command.

Installing the mentioned package, plus gcc-gfortran after it asked for that one as well, did seem to resolve the bug on my end.

Do you want me to close this issue, as you seem to understand the problem now. Or leave it open since it is still unsolved. I can still do testing if you want, but I am basically just running generic fedora 36 + ble.sh I think. It sounds like any system missing f77 is going to have a similar bug.

[akinomyoga]

I've pushed a workaround (commit 64d471a). I have also opened a pull request at the upstream bash-completion (scop/bash-completion#772).

I can still do testing if you want, but I am basically just running generic fedora 36 + ble.sh

If you are not going to use f77, now you can remove the f2c package. If so, can you again check the behavior after removing f2c?

$ sudo dnf remove f2c     # <-- uninstall the f2c package
$ bash                    # <-- start a new session
$ gcc --help              # <-- see if the problem arises

I think. It sounds like any system missing f77 is going to have a similar bug.

Any system missing f77 and, in addition, trying to ask a user to install missing packages using command_not_found_handle. I'd think I can hardly call it a bug, rather some incompatibilities between the system configuration and bash-completion. bash-completion project seems to recognize the problem (see scop/bash-completion#390 and also some code comment about the problems caused by Ubuntu/Debian's command_not_found_handle. I think the problem is that command_not_found_handle set up by the distributions Fedora/Ubuntu/etc. is badly designed. I'm actually also using Fedora 36 for my main machine but turning off command_not_found_handle in my bashrc settings for a long time (I've added the setting six years ago).

[akinomyoga]

The previous fix turned out to be incomplete by #192 (comment). I have added an additional fix d5fe1d1.

[wisnoskij]

Sorry, Canada's internet was out for all of yesterday.
And I guess our git access must still be spotty as all git commands fail for me now so I think I would have to manually copy all the files over, which would probably take a long time, so I cannot update ble.sh to test this out yet.

[akinomyoga]

Oh, I feel sorry for that. You can check the updates when the internet is recovered!

[wisnoskij]

Seems to work, at least no terminal bricking.

[akinomyoga]

Thanks!