-
-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ble-attach (or ble-reload) outputs an EOF #334
Comments
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
$ declare -p PS1 PROMPT_COMMAND | cat -v
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:
$ 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 # 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
I've commented out all scripts except the blesh ones, it still happens. Here are my |
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".
The text was updated successfully, but these errors were encountered: