Correct ble.sh sourcing in bashrc?

[telometto]

I was just wondering if [[ $- != *i* ]] && return can be removed and if the .bashrc can look like below.
The whole "SDKMAN" block was automatically added (to the bottom) by sdkman itself. There doesn't seem to be any issues (at least I haven't noticed anything) with the current layout, but since I installed ble.sh through the AUR, and it echoed that [[ $- == *i* ]] && source /usr/share/blesh/ble.sh --noattach needs to be at the top and [[ ${BLE_VERSION-} ]] && ble-attach at the bottom, I figured that it might cause problems if they aren't at the top & bottom.

This is my .bashrc:

#
# ~/.bashrc
#

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

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
PS1='[\u@\h \W]\$ '

### ================== [CUSTOM] ================== ###
#   --------------> PATH variables <--------------   #
export EDITOR=micro
export VISUAL=micro
export GPG_TTY=$(tty)
#   ----------------------------------------------   #

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

#THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!!
export SDKMAN_DIR="$HOME/.sdkman"
[[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"

[akinomyoga]

I think I need to explain the general answer in detail somewhere, so let me write it here today.

Actually, I think in most cases just writing source /path/to/ble.sh somewhere in .bashrc would probably work. But in some cases, some conflicts with other configurations may happen.

When do we need to put source ble.sh at the top?

I recommend writing source /path/to/ble.sh at the top of .bashrc to properly pick up the bind and trap settings configured by users or other Bash configuration frameworks. Even if an external configuration sets bind and trap before source /path/to/ble.sh, ble.sh actually tries to extract the existing settings by comparing them with the Bash default, but it might not work when the external configuration sets something that is the same as the Bash default. In that case, ble.sh might override the external setting with ble.sh's default. I guess it would happen rarely, but once it happened, I think it is hard for the users to identify the cause by themselves because ble.sh does something unusual. So, I present this "top & bottom configuration" as a more robust way to set up ble.sh.

This means that we can actually put external configuration before source /path/to/ble.sh if that configuration does not use bind or trap to set up its own keybindings or trap handlers.

When do we need to specify --noattach and write ble-attach explicitly in .bashrc?

The reason that I recommend explicitly writing ble-attach in .bashrc as a more robust setup is related to a possible conflict with other configurations for PROMPT_COMMAND. When one doesn't specify the option --noattach in sourcing, ble.sh tries to automatically attach to a ble.sh session using PROMPT_COMMAND. This means that ble.sh fails to attach when some other configuration just overwrites the variable PROMPT_COMMAND. Bash configurations that are appropriately designed to use PROMPT_COMMAND should keep the existing content of PROMPT_COMMAND by appending/prepending an additional string to the variable or by keeping the original value in another variable and eval's it by itself, in which case ble.sh can still properly automatically attach to a ble.sh session. The problem arises with a wrongly designed configuration that just removes the original value of PROMPT_COMMAND and just overwrites the variable. Ideally, they should be fixed at the side of such a wrongly designed configuration, but

• There are many such wild Bash configurations, unfortunately. For example, kitty's shell integration code contained such a wrong configuration, for which I submitted a fix.
• There are also many articles describing for beginners how to use PROMPT_COMMAND but don't explain the possible conflicts on the variable and describe the proper solution, which results in personal configurations of naive users that overwrite the variable PROMPT_COMMAND.
• I also recently saw a recommendation of unsetting PROMPT_COMMAND to work around another problem in an Issue of another project (oh-my-bash), which is totally wrong.

I wouldn't like to debug all of these broken external configurations and personal naive .bashrc, so decided to just describe a "more robust" way in README and the wiki.

So, if all the other configurations do not use PROMPT_COMMAND at all or are using PROMPT_COMMAND properly, you can actually just write the single line source ble.sh and do not need to explicitly write ble-attach.

Bash 5.1 newly supported an array PROMPT_COMMAND where ble.sh uses the second element for a more robust solution, so the problem would be less likely to happen. Nevertheless, the problem still arises when another configuration unsets PROMPT_COMMAND as was done in e.g. kitty's shell integration.

When do we need to write ble-attach at the bottom of .bashrc?

Once one decides to write ble-attach explicitly in .bashrc, the next question would be why I recommend writing it at the bottom of .bashrc. There are multiple reasons:

• The first reason is that, after attaching, outputting anything to stdout would break the terminal contents of the prompt and the command line ble.sh shows. The conflict happened with a nix-shell configuration.
• Also, ble.sh wants to suppress the GNU Readline outputs using stderr, so the data outputted to stderr by external configurations after attaching will also be discarded and lost.
• ble.sh sends requests to the current terminal for the terminal-identification codes and the character-width modes on attaching and expects responses from the terminal in stdin. If some other configurations try to read something from stdin after attaching, the external configuration would instead receive the terminal responses. This causes problems in both the external configuration and ble.sh; the external configuration receives some "garbage" values that it doesn't understand, and ble.sh fails to receive the expected terminal responses. I don't remember the page soon, but the actual conflict happened with a configuration explained in a blog post that tried to get the cursor position on startup.
• ble.sh needs to adjust Bash settings such as set -e, set -v, set -o posix, set -u, etc. inside ble.sh's processing in order that it works properly. These Bash settings will only be restored when user commands are executed. If any external configuration changes the setting to something that ble.sh does not expect after attaching, ble.sh can stop working. This also happened with the nix-shell configuration.
• Also, ble.sh uses PS1 at the timing of ble-attach for the first prompt, so the setup of PS1 should be finished before ble-attach.

This means that the conditions for the external configurations that can be put after ble-attach is that 1) the configuration doesn't interact with any of stdout, stderr, and stdin, 2) the configuration does not set up PS1 and other prompts, and 3) the configuration doesn't change Bash's settings such as set -evukTBx, shopt extdebug nocaseglob expand_aliases, and locale variables and TMOUT. If all of these conditions are satisfied, that configuration can be put after ble-attach.

[akinomyoga]

Here are some comments on the provided example of .bashrc:

---

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

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

If you would check the interactive session by [[ $- != *i* ]] && return, then you can actually do not need [[ $- == *i* ]] && before the sourcing ble.sh. You can write it as

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

source /usr/share/blesh/ble.sh --noattach

---

#THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!!
export SDKMAN_DIR="$HOME/.sdkman"
[[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"

It depends on what sdkman-init.sh does actually. Anyway, as far as the conditions that I described in another reply are satisfied, there should be no problem. I checked sdkman-init.sh. The script file sdkman-init.sh itself seems to be fine to put after ble-attach, but the script further sources other scripts files for which I'm not sure.

[telometto]

Thank you very much for your elaborate replies. That clears things up 😊 I think I will just stick with sdkman at the bottom, as long as it seems to be working. Should I encounter any problems, I can try to comment it out to see if that solves any eventual problems.