CODEWITHSUNDEEP
bashcolorscommand-prompt
agronskiy
agronskiy

Reputation: 367

Weird wrapping of bash prompt with coloring (`\[` and `\]` being used)

I was working on my own bash prompt when hit strange behaviour (both iTerm and Terminal.app on macos). I managed to boil it down to the minimum working example:

~/.bash_profile:

WHITE="\[\033[1;37m\]"
COLOR_NONE="\[\033[0m\]"

# This always wraps correctly
PS1="\u:\w"

# This (added coloring) wraps incorrectly when using small window.
# PS1="${WHITE}\u:\w${COLOR_NONE}"

Now create a long directory name say 

mkdir ~/very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name_very_long_name

and cd to it. Problem is: with the first version of the PS1 it wraps perfectly, while adding just one color breaks wrapping for small windows. Can anybody clarify of give a workaround? Adding \n to the end is an option, but looks ugly for short prompts.

Thanks!

Sources I have already seen:

BashFAQ/053 about colors

SO question about \[ and \]

Issue with \x01 and \x02

UPD: bash version version 3.2.57(1)-release (x86_64-apple-darwin17)

Upvotes: 5

Views: 610

Answers (1)

rici
rici

Reputation: 241681

Bash has always had trouble handling long prompts with invisible characters, so the usual practice is to avoid them. For example, you could automatically trim the length of the prompt by omitting the beginning of the path if it is too long, or you could automatically output a trailing newline if the path is very long. (In such cases, you might want to use $COLUMNS, which will normally tell you the width of the window.)

In patch 19 to bash v4.4 (which I realise is not really relevant to your environment since you seem to still be using the antique version of bash provided by a default OS X install), a long-standing bug was corrected, which had the effect of triggering a segfault in certain very rare cases of multiline prompts with both invisible and multibyte characters. The behaviour definitely changed between v4.4.18 and v4.4.19, but even with that patch very long prompts cause problems when the prompt extends to a third line.

There is a comment in lib/readline/display.c which indicates that the readline library assumes that prompts will not exceed two lines. I suggest that you use that as a limit.

Upvotes: 1

Related Questions