byobu-prompt color prompt corrupts long command lines

Bug #1809167 reported by Daniel D.
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
byobu
Fix Released
Undecided
Unassigned
byobu (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

The default byobu-prompt color prompt results in command line corruption when editing lines which exceed one line (including prompt). It's especially bad when trying to use the 'cursor-up' to get an old command line and edit it (or even see it properly), but also affects new commands lines.

For command history a workaround is to use fc -r <history_position> instead. For new lines there is no workaround with byobo-prompt sourced.

The best workaround is to comment out sourcing of byobu-prompt in ''/home/<user>/.byobu/prompt''. This gets the default .bashrc color prompt (i.e. non-byobu) which does not exhibit the same issues. The problem most likely has to do with the escape sequences used to 'prettily' colorize the prompt when the BYOBU_PROMPT is an Ubuntu derivative (i.e. the 'Use Googley colors' part) rather than Ubuntu itself.

If that is a downstream addition please let me know and I will report there (actually going to do that anyway since picking up a change to byobu will probably have to filter through byobu upstream -> ubuntu -> Pop! OS otherwise).

Tags: patch
Revision history for this message
Daniel D. (cshoredaniel-deactivatedaccount) wrote :

Here's a screenshot of the corruption happening.

Revision history for this message
owenman (owen-solberg) wrote :

I was going to open a report for the same thing and then found this one. Same problem I am sure.

I would just add that although I initially thought the problem happened only on multi-line bash history, a more careful examination shows that it happens anytime the history contains more than 33 characters.

Another oddity: cursor-up, followed by repeated cursor-left seems to work okay, but cursor-up, followed by control-a does not.

I'm using
byobu version 5.127
tmux 2.8
CentOS Linux release 7.6.1810

Revision history for this message
Daniel D. (cshoredaniel-deactivatedaccount) wrote :

So I was able to verify that if ~/.byobu/prompt contains

export BYOBU_DISTRO=Ubuntu
[ -r /usr/share/byobu/profiles/bashrc ] && . /usr/share/byobu/profiles/bashrc #byobu-prompt#

Then the problem goes ways. The issues appears to be in /usr/share/byobu/profiles/bashrc, specifically:

The "Googley Colours" terminal sequences obviously have some kind of issue solved by the more complicated Ubuntu definitions.

case "$BYOBU_DISTRO" in
   "Ubuntu")
    # Use Ubuntu colors (grey / orange / aubergine)
    PS1="${debian_chroot:+($debian_chroot)}\[\e[38;5;202m\]\$(byobu_prompt_status)\[\e[38;5;245m\]\u\[\e[00m\]@\[\e[38;5;172m\]\h\[\e[00m\]:\[\e[38;5;5m\]\w\[\e[00m\]\$(byobu_prompt_symbol) "
    export GREP_COLORS="ms=01;38;5;202:mc=01;31:sl=:cx=:fn=01;38;5;132:ln=32:bn=32:se=00;38;5;242"
    export LESS_TERMCAP_mb=$(printf '\e[01;31m') # enter blinking mode – red
    export LESS_TERMCAP_md=$(printf '\e[01;38;5;180m') # enter double-bright mode – bold light orange
    export LESS_TERMCAP_me=$(printf '\e[0m') # turn off all appearance modes (mb, md, so, us)
    export LESS_TERMCAP_se=$(printf '\e[0m') # leave standout mode
    export LESS_TERMCAP_so=$(printf '\e[03;38;5;202m') # enter standout mode – orange background highlight (or italics)
    export LESS_TERMCAP_ue=$(printf '\e[0m') # leave underline mode
    export LESS_TERMCAP_us=$(printf '\e[04;38;5;139m') # enter underline mode – underline aubergine
    # Use Ubuntu themed dircolors
    if [ -e "${BYOBU_PREFIX}/share/byobu/profiles/dircolors" ]; then
     dircolors "${BYOBU_PREFIX}/share/byobu/profiles/dircolors" > "$BYOBU_RUN_DIR/dircolors"
     . "$BYOBU_RUN_DIR/dircolors"
    fi
   ;;
   *)
    # Use Googley colors (blue / red / yellow / blue / green / red )
                                PS1="${debian_chroot:+($debian_chroot)}\[\e[31m\]\$(byobu_prompt_status)\[\e[38;5;69m\]\u\[\e[38;5;214m\]@\[\e[38;5;167m\]\h\[\e[38;5;214m\]:\[\e[38;5;71m\]\w\[\e[38;5;214m\]\$(byobu_prompt_symbol)\e[00m\] "
   ;;
  esac
 fi

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

So in Ubuntu it doesn't happen? When I start byobu in bionic, my shell gets BYOBU_DISTRO set to Ubuntu:
andreas@nsnx:~$ byobu
andreas@nsnx:~$ echo $BYOBU_DISTRO
Ubuntu

My prompt (PS1) is "boring", though, no extra colors.

Revision history for this message
David Parrish (daveparrish) wrote :

The Byobu prompt works fine for me in Ubuntu. I see the issues described above in Arch Linux.

Revision history for this message
Daniel D. (cshoredaniel-deactivatedaccount) wrote :

I haven't tested from Ubuntu proper -- I didn't realize at first about the difference in code paths for Ubuntu derivatives. Since 'pretending' to be Ubuntu for byobu purposes, and when I reported for System76 they didn't see the issue on Ubuntu, I'd say that it probably doesn't happen on Ubuntu proper.

Revision history for this message
David Parrish (daveparrish) wrote :

I implemented a fix and then noticed someone else also found a fix on Github. https://github.com/dustinkirkland/byobu/pull/30

Patch attached.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "non_ubuntu_color_fix.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi David,
summarizing what was found so far.

1. in Ubuntu this doesn't occurs since we use a less colorful PS1
   -> marking the Ubuntu task as invalid
2. There already is an upstream PR to fix it in the byobu project
   https://github.com/dustinkirkland/byobu/pull/30
   (yet unhanlded)

I agree that handling that PR would be the right way to fix it eventually.

@Kirkland - are you still maintaining byobu upstream? If so ,do you do that on github or launchpad or where exactly would you want PRs/Bugs to be directed to?

Changed in byobu (Ubuntu):
status: New → Invalid
Revision history for this message
Gunnar Thielebein (lorem-ipsum) wrote :

I can experience the same issue with byobu in Fedora 30.

Is there a chance for a new release including that patch?

Revision history for this message
Gunnar Thielebein (lorem-ipsum) wrote :

Sorry for the noise.
Just recognise that 5.128 is out but Fedora30 still ships 5.127.

Changed in byobu:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.