[starship] eval after bleopt necessary?

[teutat3s]

ble version: 0.4.0-devel4+f16c0d8 Bash version: 5.2.15(1)-release (x86_64-pc-linux-gnu)

In /etc/bashrc I have:

if [[ $TERM != "dumb" && (-z $INSIDE_EMACS || $INSIDE_EMACS == "vterm") ]]; then
  export STARSHIP_CONFIG=/nix/store/h9cak4nnnlsb52hvm79pggz9abb848gl-starship.toml
  eval "$(/nix/store/phcx9a2plh8gs0a5xz18chg1bywfymr1-starship-1.15.0/bin/starship init bash)"
fi

When using the newest version of ble.sh (latest commit from master branch), I need to run the eval command a second time in ~/.bashrc after the section with all bleopt and ble-bind statements, just before [[ ${BLE_VERSION-} ]] && ble-attach

~/.bashrc

...
bleopt complete_menu_style=desc

# Bash vim mode keybindings
if [[ $- == *i* ]]; then # in interactive session
  set -o vi

  ble-bind -m vi_imap -f 'ENTER' 'vi_imap/complete'
  ble-bind -m vi_imap -f 'TAB' 'vi_imap/complete'

  ble-bind -m vi_imap -f 'j j' 'vi_imap/normal-mode'
  ble-bind -m vi_imap -f 'ESC' 'vi_imap/normal-mode'

  ble-bind -m vi_nmap -f 'h' 'vi_nmap/insert-mode'
  ble-bind -m vi_nmap -f 'i' 'vi-command/backward-line'
  ble-bind -m vi_nmap -f 'j' 'vi-command/backward-char'
  ble-bind -m vi_nmap -f 'k' 'vi-command/forward-line'
  ble-bind -m vi_nmap -f 'l' 'vi-command/forward-char'

  ble-bind -m vi_imap -f 'C-c' discard-line
fi

# end of .bashrc

# Somehow we need to ensure starship starts later than ble.sh
eval "$(/nix/store/phcx9a2plh8gs0a5xz18chg1bywfymr1-starship-1.15.0/bin/starship init bash)"

[[ ${BLE_VERSION-} ]] && ble-attach

...

I am unsure if this is a packaging issue, as this happens on NixOS 23.05, with a custom packaged version of ble.sh. When using the provided 0.4.0-devel3 release archive from GitHub, the change is not required for starship to start with a single eval in /etc/bashrc.

Without the second eval, ble.sh 0.4.0-devel4+f16c0d8 starts fine, but I only see the bash:$ prompt instead of the starship prompt.

[akinomyoga]

Sorry for the long blank, but the provided context is unclear. At least, I cannot reproduce the problem with the settings you provided.

The general answer to a question on the ordering of the configuration is mentioned in README §1.3. Whether eval after sourcing ble.sh is really necessary or not depends on the situation, (which is not clear for the present case by the provided information), but you should also look at https://github.com/akinomyoga/ble.sh/discussions/254#discussioncomment-4284757 which is linked from README §1.3.

To answer the question for your specific case, I need clarifications and context from you. I'm sorry, but I need to ask many quetions.

In /etc/bashrc I have:

• Q1: Where is /etc/bashrc sourced from? For example, is it explicitly sourced from your .bashrc? In that case, could you source /etc/bashrc after sourcing .bashrc? [ Note: If you don't source /etc/bashrc from .bashrc or any other Bash configuration, you might be using bash with a special build flag to automatically source /etc/bashrc on the startup. ]
• Q2: Also, where do you source ble.sh? Is it directly from .bashrc or from another file that is maintained by NixOS, Home Manager, etc.?

I need to run the eval command a second time in ~/.bashrc after the section with all bleopt and ble-bind statements, just before [[ ${BLE_VERSION-} ]] && ble-attach

• Q3: Does that mean that bleopt and ble-bind is related to the issue? Does the problem only happen when the settings of bleopt and ble-bind exist? What happens when all of the bleopt and ble-bind settings are commented out?
• Q4: Have you checked the behavior when eval is performed before the bleopt and ble-bind settings but after sourcing ble.sh?

• Q5: I don't find any line sourcing ble.sh in the provided configuration. This means that you are omitting some parts of ~/.bashrc. Could you provide a minimal but complete ~/.bashrc that reproduces the problem?

  [ Note: As I cannot reproduce the problem, I need to ask you to identify the minimal setup that reproduces the problem. You can try it by commenting out parts of ~/.bashrc and see if it changes the behavior. If the problem doesn't change, the part commented out is not related to the problem. In this way, you can incrementally comment out the irrelavant parts to create a minimal setup reproducing the problem. ]

I am unsure if this is a packaging issue, as this happens on NixOS 23.05, with a custom packaged version of ble.sh. When using the provided 0.4.0-devel3 release archive from GitHub, the change is not required for starship to start with a single eval in /etc/bashrc.

• Q6: How is each of the mentioned "custom packaged version of ble.sh" and the 0.4.0-devel3 release archive is configured? Are they configured in exactly the same way? Or, for example, one is installed by defining *.nix, etc. and the other is installed by directly running git clone or wget/curl as described in ble.sh's README? Could you check if the behaviors of 0.4.0-devel3 and 0.4.0-devel4 are still different when both are installed in exactly the same way?
• Q7: Is the problem related to NixOS? For example, doesn't the problem happen with starship installed in a different way?