ble-attach (or ble-reload) outputs an EOF about ble.sh HOT 3 OPEN

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.

from ble.sh.

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

from ble.sh.

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

from ble.sh.