3

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)

agronskiy
  • 300
  • 4
  • 11
  • Do you mean that the second version works with short paths? – vdavid Aug 12 '18 at 19:14
  • Yes, wrapping prompt on long paths and narrow terminal breaks with the second option. – agronskiy Aug 12 '18 at 20:34
  • 1
    Then I guess you have hit a limit with your bash interpreter. You may try to trim the directory, e.g. https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-PROMPT_005fDIRTRIM or try something like http://zork.net/~st/jottings/How_to_limit_the_length_of_your_bash_prompt.html or https://www.macworld.com/article/1050257/bashprompt.html or https://askubuntu.com/questions/17723/trim-the-terminal-command-prompt-working-directory – vdavid Aug 12 '18 at 20:57
  • What version of bash are you using? (Please update the question with this information.) – rici Aug 13 '18 at 00:02
  • 1
    From the `bash` tag: For questions about ***scripts written for the Bash command shell.*** ... ***Questions about interactive use of Bash are more likely to be on-topic on Super User than on Stack Overflow.*** – paxdiablo Aug 13 '18 at 01:56
  • I'm sorry for posting it wrongly then, was also trying to figure it out between SO and SU. @rici I'll update. – agronskiy Aug 13 '18 at 14:25
  • 1
    @agronskiy: I didn't realise you were using such an old version. I rewrote my answer to be a bit more general. – rici Aug 13 '18 at 16:08

1 Answers1

1

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.

rici
  • 234,347
  • 28
  • 237
  • 341