ble-attach (or ble-reload) outputs an EOF

[Emojigit]

$ ble/widget/display-shell-version
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) [Arch Linux]
ble.sh, version 0.4.0-devel4+f16c0d80 (noarch) [git 2.41.0, GNU Make 4.4.1, GNU Awk 5.2.2, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.0-p9, GNU MP 6.2.1)]
bash-completion, version 2.11 (hash:2d02f73e803daa87a06e94e33b2a7b3e672a2c0c, 76338 bytes) (noarch)
locale: LANG=zh_HK.UTF-8
terminal: TERM=xterm-256color wcwidth=15.0-west/15.0-2+ri, konsole:220380 (1;115;0)
$ pacman -Q blesh-git
blesh-git 0.4.0_devel4.r1968.f16c0d80-1

This is a minor yet annoying issue. Every time blesh is reloaded (i.e. via source .bashrc), a [ble: EOF] appears on the next line.

# ^ Other things in .bashrc... ^ #

# ble.sh setup. Place all configurations in $HOME/.blerc.
[[ $- == *i* ]] && source /usr/share/blesh/ble.sh --noattach --rcfile "$HOME/.blerc"
[[ ${BLE_VERSION-} ]] && ble-attach

(Ignore the "already in PATH" thing, that's my own configurations.)

I can understand why it is here (because ble-attach is not printing a carriage return). Normally, the [ble: EOF] is used to force a carriage return after programs not printing one while letting the user know about that, like this:

In the second case, the [ble: EOF] did a great job. However, that's absolutely not the case of ble-reload. The one in the first case is annoying as it forced me to type on the next line.

I used the bug report template to draft this issue. Sorry if this is not a "bug report".

[akinomyoga]

Thanks for the report. The problem doesn't reproduce in my environment. It is likely to be some compatibility issue with other settings in your ~/.bashrc or some Bash configurations provided by the system.

For example, this problem will happen when the prompt is not shown through the result of evaluating PS1 but directly through outputting something to TTY from the commands in PS1 or PROMPT_COMMAND. (If that is the case, it would cause issues even without ble.sh)

• Q1: What are the outputs of the following commands?

$ declare -p PS1 PROMPT_COMMAND | cat -v

• Q2: Does the problem reproduce when you comment out all the other configurations in your ~/.bashrc? (Be careful to back up your ~/.bash_history if you increase the history size from the Bash default, 500.).
  • If the problem doesn't arise after commenting out the others, could you identify which setting causes the interference?
  • If the problem still persists, could you also check the behavior when you start the child Bash session with the reduced .bashrc? The child Bash session can be started by running another Bash process by the command bash inside a Bash interactive session.

I used the bug report template to draft this issue. Sorry if this is not a "bug report".

Don't worry. This is actually the template for the general problems which covers bugs, compatibility issues, or wrong user configurations. It is usually hard to determine at the beginning whether it is a bug or any other type of issue.

[Emojigit]

Thank you for your reply. Here are my answers:

Q1: What are the outputs of the following commands?

$ declare -p PS1 PROMPT_COMMAND | cat -v
declare -- PS1="\\[\\e]0;\\u@\\h: \\w\\a\\]\\[\\033[01;32m\\]\\u@\\h\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w\\[\\033[00m\\]\\\$ "
declare -a PROMPT_COMMAND=([0]="_opam_env_hook;printf \"\\033]0;%s@%s:%s\\007\" \"\${USER}\" \"\${HOSTNAME%%.*}\" \"\${PWD/#\$HOME/\\~}\"")

In addition, here are the .bashrc codes declaring my PS1. It is based on the Ubuntu version, but I've removed the Ubuntu-specific codes (i.e. debian-chroot) to optimize it on Arch Linux.

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	# We have color support; assume it's compliant with Ecma-48
	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
	# a case would tend to support setf rather than setaf.)
	color_prompt=yes
    else
	color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

Q2: Does the problem reproduce when you comment out all the other configurations in your ~/.bashrc?

I've commented out all scripts except the blesh ones, it still happens.

Here are my .bashrc and related scripts: https://gist.github.com/Emojigit/27d420b7de1ef7a940061e79aa7f655e

[akinomyoga]

Thank you for providing your additional context, and sorry for the delayed reply. I'm recently busy, so it might further delay.