Receiving strange print-outs in terminal

[jkemp814]

ble version: 0.4.0-devel4+a7eb5d0
Bash version: .2.21(1)-release

When updating my system: Fedora Linux 39 Silverblue, I get many of these print-outs. I'm using gnome-terminal, but they occur in Alacritty also.

10:14:44 james@HP-Z840 ~ → rpm-ostree upgrade
[1] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[2] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[3] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[4] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[5] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[1] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[2] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[3] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[4] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[1] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[2] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[3] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[4] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[1] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[2] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[3] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[4] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[1] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[2] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[3] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"
[4] Done exec 2>> "$_ble_edit_io_fname2" | exec 2>> "$_ble_edit_io_fname2"

[akinomyoga]

Thanks for the report. I currently don't have time to set up a similar environment and see if it reproduces on my side. For the time being I have several questions.

• Q1: Does it happen only when you run rpm-ostree? Or do you mean that after running rpm-ostree, Bash starts to produce those errors for every daily command?
• Q2: What are the results of the following commands?

$ type -a rpm-ostree
$ declare -p PROMPT_COMMAND
$ trap -p
$ builtin trap -p

• Q3: How do you source ble.sh in your ~/.bashrc? Could you copy and paste the lines near the place where ble.sh is sourced?

[jkemp814]

I put ble.sh at the very top, and at the very bottom, just like the instructions advised.

[[ $- == *i* ]] && source "$HOME/.local/share/blesh/ble.sh" --noattach

case $- in
  *i*) ;;
    *) return;;
esac

# Path to your oh-my-bash installation.
export OSH='/var/home/james/.oh-my-bash'

and at the bottom:

. "$HOME/.cargo/env"
eval "$(zoxide init bash)"
[ -f ~/.fzf.bash ] && source ~/.fzf.bash
HELIX_RUNTIME=/var/home/james/helix/runtime
ANSIBLE_HOME=~/.ansible

# Add this line at the end of .bashrc:
[[ ${BLE_VERSION-} ]] && ble-attach

It seems to show all those errors after I run the rpm-ostree upgradeover several times in a row. It doesn't display those errors all the time.

type -a rpm-ostree
rpm-ostree is /usr/bin/rpm-ostree

declare -p PROMPT_COMMAND
declare -a PROMPT_COMMAND=([0]=$'__bp_precmd_invoke_cmd\n__zoxide_hook;_omb_util_prompt_command_hook\n__bp_interactive_mode')

trap -p
trap -- '__bp_preexec_invoke_exec "$_"' DEBUG

builtin trap -p
trap -- 'ble/builtin/trap/.handler 0 "$BASH_COMMAND" "$@"; builtin eval -- "${_ble_builtin_trap_postproc[0]}" \# "${_ble_builtin_trap_lastarg[0]}"' EXIT
trap -- 'ble/builtin/trap/.handler 2 "$BASH_COMMAND" "$@"; builtin eval -- "${_ble_builtin_trap_postproc[2]}" \# "${_ble_builtin_trap_lastarg[2]}"' SIGINT
trap -- 'ble/builtin/trap/.handler 28 "$BASH_COMMAND" "$@"; builtin eval -- "${_ble_builtin_trap_postproc[28]}" \# "${_ble_builtin_trap_lastarg[28]}"' SIGWINCH
trap -- 'ble/builtin/trap/.handler 1000 "$BASH_COMMAND" "$@"; builtin eval -- "${_ble_builtin_trap_postproc[1000]}" \# 
"${_ble_builtin_trap_lastarg[1000]}"' DEBUG

[akinomyoga]

Thank you.

• Q4: What is the output of the following command?

$ ble/widget/display-shell-version

[jkemp814]

02:32:24 james@HP-Z840 ~ → ble/widget/display-shell-version
GNU bash, version 5.2.21(1)-release (x86_64-redhat-linux-gnu) [Fedora Linux 39.20231122.0 (Silverblue)]
ble.sh, version 0.4.0-devel4+a7eb5d0 (noarch) [git 2.42.0, GNU Make 4.4.1, GNU Awk 5.2.2, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.0-p12, GNU MP 6.2.1)]
bash-completion, version 2.11 (hash:1a7f5634b4c9816716b69a7824e0b51cfde2bca3, 76332 bytes) (noarch)
fzf key-bindings, version +6b99399c (noarch)
WARNING: fzf integration "integration/fzf-key-bindings" is not activated.
fzf completion, version +6b99399c (noarch)
WARNING: fzf integration "integration/fzf-completion" is not activated.
bash-preexec, (hash:b3e19ff4806c83bfb6c2cf55fff0a140de1637f5, 13726 bytes) (noarch)
oh-my-bash (font), version 1.0.0+e2917d67 (noarch), aliases(general), completions(awscli defaults gem git kubectl minikube npm pip pip3 ssh system todo), plugins(ansible aws bashmarks git kubectl npm pyenv sudo xterm zoxide)
locale: LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=15.0-west/15.1-2+ri, vte:7401 (65;7401;1)

[jkemp814]

So far, I have not received any of those errors messages. Not sure, if a restart cleared things up.

[akinomyoga]

Have you experienced the error messages after that? I still cannot reproduce this.

If you can still reproduce the problem consistently, I would like to ask you to identify the minimal setup with the error messages. The above result of ble/widget/display-shell-version implies that many settings are loaded in your environment. More specifically,

• Does the problem persist after disabling fzf key-bindings?
• Does the problem persist after disabling fzf completions?
• Does the problem reproduce after disabling bash-preexec?
• Does the problem reproduce after disabling oh-my-bash?
• Does the problem reproduce with only ble.sh loaded?

[jkemp814]

I have hadn't gotten any of those messages anymore.

[akinomyoga]

OK, thanks for the information. Then, could you close the issue for now? If you happen to face the problem in the future, you can reopen this issue at that time.

[jkemp814]

Okay, new development. I ditched the .profile file. Added all of it to .bash_profile. Restarted and now there are no strange printouts and after updating Oh-My-Bash it completed normally and fell back to prompt. That's with zoxide, cargo, and fzf all enabled. Will continue to monitor the situation.

[jkemp814]

I have a question about zoxide and fzf. Should I have those settings in my .bash_profile file at all? After I install fzf the package added those settings. I notice BLE have integrations during the update. The only reason I have them there was before starting to use ble.sh. Having zoxide and fzf installed is all that's needed, and ble.sh does the rest?

[akinomyoga]

Sorry, I seem to have missed your comment. Maybe you already solved the problem or you don't use ble.sh any more, but let me leave an anwer.

I have a question about zoxide and fzf. Should I have those settings in my .bash_profile file at all?

The answer is different between Zoxide and Fzf.

• Zoxide: You can keep the zoxide setting there (though the correct place is .bashrc instead of .bash_profile. If you put the interactive settings in .bash_profile, the settings will be disabled in the child Bash sessions).
• Fzf: To use fzf with ble.sh, one needs to follow the instruction on README §2.8. The old settings in .bash_profile should be removed, or it should be moved to .bashrc and then conditionally turned on only when ble.sh is inactive.

Having zoxide and fzf installed is all that's needed, and ble.sh does the rest?

No, it's not automatically. If you'd like to set up zoxide and fzf, you need to explicitly call it. For the zoxide setting, you