Open Emojigit opened 1 year ago
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)
$ declare -p PS1 PROMPT_COMMAND | cat -v
~/.bashrc
? (Be careful to back up your ~/.bash_history
if you increase the history size from the Bash default, 500.).
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.
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
Thank you for providing your additional context, and sorry for the delayed reply. I'm recently busy, so it might further delay.
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.(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 ofble-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".