0

Here's my .bash_profile

export CLICOLOR=1
export LSCOLORS=exfxcxdxbxegedabagacad

# define colors
C_DEFAULT="\[\033[m\]"
C_WHITE="\[\033[1m\]"
C_BLACK="\[\033[30m\]"
C_RED="\[\033[31m\]"
C_GREEN="\[\033[32m\]"
C_YELLOW="\[\033[33m\]"
C_BLUE="\[\033[34m\]"
C_PURPLE="\[\033[35m\]"
C_CYAN="\[\033[36m\]"
C_LIGHTGRAY="\[\033[37m\]"
C_DARKGRAY="\[\033[1;30m\]"
C_LIGHTRED="\[\033[1;31m\]"
C_LIGHTGREEN="\[\033[1;32m\]"
C_LIGHTYELLOW="\[\033[1;33m\]"
C_LIGHTBLUE="\[\033[1;34m\]"
C_LIGHTPURPLE="\[\033[1;35m\]"
C_LIGHTCYAN="\[\033[1;36m\]"
C_BG_BLACK="\[\033[40m\]"
C_BG_RED="\[\033[41m\]"
C_BG_GREEN="\[\033[42m\]"
C_BG_YELLOW="\[\033[43m\]"
C_BG_BLUE="\[\033[44m\]"
C_BG_PURPLE="\[\033[45m\]"
C_BG_CYAN="\[\033[46m\]"
C_BG_LIGHTGRAY="\[\033[47m\]"

# Prompt
if [ -f $(brew --prefix)/etc/bash_completion ]; then
  . $(brew --prefix)/etc/bash_completion
fi

source $(brew --prefix)/etc/bash_completion.d/git-prompt.sh
GIT_PS1_SHOWDIRTYSTATE=true

# PS1="\h:\W \u\$(__git_ps1 \" (%s) \")\$"
PS1="$C_YELLOW\w $C_PURPLE\$(__git_ps1 \"(%s) \")$C_DEFAULT\n ☠️   "

When I enter/copy-paste a long line, it doesn't wrap to a new line. Instead, it overwrites the existing one. It also won't erase all of the characters if I backspace to beginning.

I looked at some other answers, and they all suggest the wrapping might be the issue, but everything appears to be properly wrapped?

1

BASH is counting all characters, printable or not, as the length of the prompt. The calculated length of the prompt determines where the wrap occurs. The calculated length is the variable that needs to change. Removing the space after ☠️, and adding another \[ \] causes BASH to calculate the position for the wrap correctly on my current machine using macOS High Sierra, BASH 4.4.12, and iTerm 3.1.4.

PS1="$C_YELLOW\w $C_PURPLE\$(__git_ps1 \"(%s) \")$C_DEFAULT\n☠️\[ \]"
  • Hmm. I currently have a prompt with unwrapped trailing characters (including a final space) and no issues. Doesn't mean your suggestion won't work but it doesn't seem like that should be necessary. – B Layer Oct 24 '17 at 14:55
  • That worked! Thanks so much for the help :) – Kevin Whitaker Oct 24 '17 at 15:39
  • Sure thing. @BLayer is on the right track, too. I came up with a quick hack, but it doesn't really pinpoint any underlying issues that we can't see. I offered a quick hack because this behavior can sometimes be difficult to find. – Christopher Oct 24 '17 at 15:56
  • Right. @KevinWhitaker as Christopher suggests the modification might not have fixed the offending part. If the prompt string's effective length was off by one then masking any single character could "fix" it. But there may still be an unwrapped escape code. Just don't change the prompt further and you should be okay. ;) – B Layer Oct 24 '17 at 18:31
  • My educated guess, on the assumption that __git_ps1 is not faulty, is to look at that multibyte character first. – JdeBP Oct 24 '17 at 18:52
3

** If Christopher's answer doesn't solve it for you...

Every escape code needs to be surrounded by \[ and \]. Miss just a single one or have a mismatched pair and you'll probably end up with issues like you're seeing. I don't know what's in __git_ps1 so it's hard to say what's wrong.

If you're still stuck here's a little "debugging tip". :) You can do a simple, manual inspection by dumping your prompt into a text file and viewing it in vi. This will ensure nothing is rendered and you see actual characters (e.g. versus just doing echo $PS1 from command line).

echo $PS1 > ps1
vi ps1

If there are a lot of codes you can check that you have matched number of brackets by entering :%s/\\[//n and then :%s/\\]//n. That'll give you a count of opening and closing escape brackets...at least you'll be able to rule out any non-paired brackets by confirm both counts are the same. (I have fairly complex prompts and have been bitten by the mismatch bug more than once!)

Still can't figure it out? Copy the contents of that file here so we can inspect it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.