starship: Ridiculously long prompts sometimes don't line-wrap correctly

Current Behavior

When the prompt is ludicrously long line-wrapping breaks.

Expected Behavior

It should just line wrap

Additional context/Screenshots

Without starship, and with a boring old PS1 setting very long prompts line-wrap in narrow terminals: Screenshot 2022-03-31 at 15 18 30

But with starship, line-wrapping can sometimes go all wibbly with very long prompts. In this screen shot you can see that it’s just fine with a short prompt but when I change to a git branch with a ludicrously long name the prompt breaks badly: Screenshot 2022-03-31 at 15 20 32

This may be down to some not-quite-correct escaping/printing of ANSI colour codes, as seen here: Screenshot 2022-03-31 at 15 24 34

Environment

  • Starship version: 1.5.4
  • bash version: GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin20) Copyright © 2007 Free Software Foundation, Inc.
  • Operating system: Mac OS 11.6.4
  • Terminal emulator: iTerm.app 3.4.15
  • Git Commit Hash:
  • Branch/Tag:
  • Rust Version: rustc 1.59.0
  • Rust channel: release
  • Build Time: 2022-03-24 19:12:59 +00:00

Relevant Shell Configuration

# sets window title
export PROMPT_COMMAND='echo -ne "\033]0;${HOSTNAME}: $(realpath .)\007"'
# this also puts stuff in $PROMPT_COMMAND
eval "$(direnv hook bash)"
...
eval "$(starship init bash)"

and checkwinsize is on and is setting $COLUMNS correctly when I change the size of the terminal.

$ shopt|grep win
checkwinsize   	on

Starship Configuration

add_newline = false

[character]
error_symbol = "[\\$](bold red)"
success_symbol = "[\\$](bold green)"

[cmd_duration]
disabled = true
[custom.c]
command = "cc --version|awk '/clang/ { printf \"clang \" } /Free Software Foundation/ { printf \"gcc \" }'; cc -dumpversion"
extensions = ["c", "h", "xs"]
format = "using [custom.C $output ](149 bold)"

[directory]
truncate_to_repo = true
truncation_length = 0
truncation_symbol = " …/"

[git_branch]
format = "[on $branch ]($style)"

[line_break]
disabled = true

[nodejs]
disabled = true

[perl]
detect_extensions = ["pl", "pm"]
format = "using [$symbol ($version )]($style)"
symbol = "perl"


About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 1
  • Comments: 16 (9 by maintainers)

Most upvoted comments

@davidkna THANK YOU! It took me a while to track it down, but in the end this was the one line change that I needed:

-export LC_ALL=C
+export LC_ALL=en_US.UTF-8`

For those stumbling on this issue and getting royally confused by the talk about Bash versions: Ubuntu 20.04’s default Bash 5.0 works fine for me. No need to upgrade to Bash 5.1. However, if you’re running Bash 3, that might be a different story and an upgrade might be needed.

FWIW I was having the same issue on macOS after upgrading to bash 5.1 using homebrew.

This bug only occurred after enabling the aws module and logging in to an aws account. The fix was to remove the $symbol from the aws module’s format. Does that suggest it’s an encoding issue for me too?

I’m suing iTerm2 which is set to use UTF8 encoding and has the Use Unicode Version 9 Widths setting on which is the usually suggested fix for this sort of thing. But just pasting ☁️ into my terminal makes the space between my prompt and terminal input disappear.

@r3h0 In that case, does PS1="🚀 " trigger the bug? Your issue is more likely caused by some kind of Unicode mishandling in bash (readline?).

It seems like @DrHyde is having a different kind of line wrapping issue caused by incorrect ANSI control sequence handling. To avoid this, starship wraps these in \[ and \] when using bash, but for bash 3 this doesn’t seem to be sufficient.