Terminal prompt overwrites current line

Question

I have an issue with my terminal prompt line. When the line is too long it wraps on the same line and then Up arrow makes it look even worse.

I have already checked Terminal prompt not wrapping correctly, but it looks like I am apparently closing all the squared brackets for non printable characters.

This is my PS1:

\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot) }\[\033[01;36m\]\u@\h\[\033[00m\]\033[01;34m\]\w\033[00m\][$(type __git_ps1 >/dev/null 2>&1 && __git_ps1 "(%s)")]

Consider this as my standard prompt line

MELISC@work~/dev/bin_tools[((main))]

I was able to get

assdasdasdasdasdadasdsadadasdaddasdadadasdadsadasdsa((main))] asdsadsadsadsadasdasdassdasdasdassdasdassdasdasdasdasdasdasdsadsad

I have already checked my .bashrc

I have and shopt -s checkwinsize should autocheck the columns

Answer 1

You've completely banjanxed the Bourne Again shell's idea of what's been printed and what it has to erase/rewrite as it displays command history and lets you edit the command line.

Breaking your prompt down into sections:

1. \[\e]0;\u@\h: \w\a\] — non-printing characters, properly enclosed
2. ${debian_chroot:+($debian_chroot) } — printing characters only, presumably
3. \[\033[01;36m\] — non-printing characters, properly enclosed
4. \u@\h — printing characters only
5. \[\033[00m\] — non-printing characters, properly enclosed
6. \033[01;34m\] — non-printing characters, improperly enclosed so the Bourne Again shell does not know that they are
7. \w\033[00m\] — an erroneous mixture of printing and non-printing characters
8. [$(type __git_ps1 >/dev/null 2>&1 && __git_ps1 "(%s)")] — printing characters only, presumably

I've given this advice before, but it is general advice that applies here as well:

• Use either \e or \033 consistently, for your own sanity.
• Make your \[ and \] strictly matching non-nesting pairs.
• Make sure that all non-printing sequences are within \[ and \] (and that, conversely, that all printing sequences are not).

(This is why I personally prefer the Z Shell and its alternative prompt expansion mechanism for when I want wacky coloured prompts. It knows that things like %F{green} aren't printing sequences, without having to be told; and it also works out the correct escape sequences from terminfo, without having them hardwired.)

Answer 2

While JdeBP's answer is excellent, I thought I'd add the one that worked for me since my PS1 was already proper. I originally posted this on a related Issue (#2713) on the WSL repo on GitHub:

---

I'd like to add a not here for posterity, because this issue has been driving me nuts. I think I finally found the cause, at least for me, so hopefully this helps others. I have seen this issue on various systems (builds 18362 - 18975) with various distros. I ensured 100% the syntax of my PS1 in my .bashrc was correct and all non-printing characters were properly escaped etc.

The issue for me was with the Console Properties. I installed my WSL distros (Ubuntu, Debian, and Kali) through the Microsoft Store, and ran the apps from my Start Menu. This launches WSL in a Linux branded classic Windows Command Prompt console as I understand. (BTW, launching from a folder with Shift+Right-click / "Open linux shell here" opens the same Console window).

Whatever the case, the point is when you right-click the resulting console title bar, click Properties, then select the option to "Wrap text output on resize" this is what resolved the issue for me.

Now I can properly enter commands that wrap around to the next line and can move my cursor around appropriately. This is definitely a bug somewhere, but I don't know where the fault lies.