Terminal prompt not wrapping correctly

Question

I have an issue where if I type in very long commands in bash the terminal will not render what I'm typing correctly. I'd expect that if I had a command like the following:

username@someserver ~/somepath $ ssh -i /path/to/private/key
myusername@something.someserver.com

The command should render on two lines. Instead it will often wrap around and start writing over the top of my prompt, somewhat like this:

myreallylongusername@something.somelongserver.comh -i /path/to/private/key

If I decide to go back and change some argument there's no telling where the cursor will show up, sometimes in the middle of the prompt, but usually on the line above where I'm typing.

Additional fun happens when when I Up to a previous command. I've tried this in both gnome-terminal and terminator and on i3 and Cinnamon. Someone suggested it was my prompt, so here that is:

\[\033[01;32m\]\u:\[\033[01;34m\] \W\033[01;34m \$\[\033[00m\]

Ctrll, reset, and clear all do what they say, but when I type the command back in or Up the same things happens.

I checked and checkwinsize is enabled in bash. This happens on 80x24 and other window sizes.

Is this just something I learn to live with? Is there some piece of magic which I should know? I've settled for just using a really short prompt, but that doesn't fix the issue.

So using the command env -i bash --norc fixes it. The $COLUMNS and $LINES match. Does that mean that there's something funny with my .bashrc? — Muricula, Dec 20 '13 at 00:44
So I commented out my .bashrc and wound up isolating my prompt as the problematic part, specifically the coloration syntax involved. What's wrong with the PS1 above? — Muricula, Dec 20 '13 at 00:53
\[\033[01;32m\]\u: \[\033[01;34m\]\W \[\033[01;34m\] \$ \[\033[0m\] seems to avoid the weirdness in the behavior - but don't know if it respects your original prompt completely... — , Dec 20 '13 at 01:19

score 280 · Accepted Answer · edited Jun 11 '20 at 12:04

280

Non-printable sequences should be enclosed in \[ and \]. Looking at your PS1 it has a unenclosed sequence after \W. But, the second entry is redundant as well as it repeats the previous statement "1;34".

\[\033[01;32m\]\u:\[\033[01;34m\] \W\033[01;34m \$\[\033[00m\]
                  |_____________|               |_|
                         |                       |
                         +--- Let this apply to this as well.

As such this should have intended coloring:

\[\033[1;32m\]\u:\[\033[1;34m\] \W \$\[\033[0m\]
                               |_____|
                                  |
                                  +---- Bold blue.

Keeping the "original" this should also work:

\[\033[1;32m\]\u:\[\033[1;34m\] \W\[\033[1;34m\] \$\[\033[0m\]
                                  |_|         |_|
                                   |           |
                                   +-----------+-- Enclose in \[ \]

Edit:

The reason for the behavior is because bash believes the prompt is longer then it actually is. As a simple example, if one use:

PS1="\033[0;34m$"
       1 2345678

The prompt is believed to be 8 characters and not 1. As such if terminal window is 20 columns, after typing 12 characters, it is believed to be 20 and wraps around. This is also evident if one then try to do backspace or Ctrl+u. It stops at column 9.

However it also does not start new line unless one are on last column, as a result the first line is overwritten.

If one keep typing the line should wrap to next line after 32 characters.

edited Jun 11 '20 at 12:04

Community

1

answered Dec 20 '13 at 01:55

Runium

28,811

If you have - or anyone - has an explanation as to what exactly in the original sequence caused the line to repeat over itself, I'd be interested in knowing that. Also +1 for how you showed this visually. – Dec 20 '13 at 02:42
1

@illuminÉ: Have not looked at the source, but added an update with a note on behavior from observation. – Runium Dec 20 '13 at 03:26
Just in case you are facing any problems, you can use this website to create a new one - http://bashrcgenerator.com/ – divinedragon Dec 11 '15 at 06:12
This is amazing, thank you @Runium - would you mind sharing how you knew this? I would love to find some documentation on this. – nycynik Mar 27 '17 at 19:57
3

@nycynik: Observation. I guess the closest to documentation on this is the source code ... – Runium Mar 30 '17 at 21:17
6

Not all heroes wear capes. – Alexander Lallier Aug 29 '19 at 13:40
I have the default prompt in Debian: PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '. How should I repair this one? – z32a7ul Mar 05 '21 at 21:09
i used to use \e[ ... m for the color codes and had this problem too. Now, switching to \[\033[ ... m\[ it's all fine! – jamacoe Sep 22 '22 at 07:18
In my case this was only part of the solution. The other issue was that the admins had pre-set PROMPT_COMMAND which was interfering somehow with prompt printing. – Mark Dominus Oct 27 '23 at 15:41

score 105 · Answer 2 · edited Mar 24 '18 at 06:01

105

It is mostly to do with the size of the window assumed by the terminal is not the same as your actual window size. If you are using bash, you can try this.

$ shopt checkwinsize

If you don't get

checkwinsize    on

Then activate it with

$ shopt -s checkwinsize

Then just attempt running another command (like ls) or resizing the window once, the above works for me every time.

For Redhat systems particularly, the issue is often caused by misconfiguring ~/.bashrc not to call /etc/bashrc. Normally, bash loads ~/.bashrc which is expected to call /etc/bashrc, which by default contains shopt -s checkwinsize.

edited Mar 24 '18 at 06:01

αғsнιη

41,407

answered Nov 14 '14 at 06:34

saketrp

1,323
1
10
9

Had the same problem with OS X, apparently if you call "login" to start your terminal, it starts bash in a way that reads /etc/bashrc, but if you just call straight to bash, the ~/.bashrc doesn't source things by default so you get the odd wrapping effect. Thanks! – rogerdpack Sep 11 '15 at 22:16
1

This worked for me as well. Colors were not on in this particular server, calling correct /etc/bashrc, everything else was good to go...turns out this is the cause of the wrapping issues. – dhaupin Nov 20 '15 at 20:23
See also http://unix.stackexchange.com/a/61608/2221 – astrojuanlu May 04 '16 at 10:17
1

Looks like a good solution. But it doesn't work in my ssh session, though. Not sure why. I have run the command shopt -s checkwinsize in the ssh session. But the wrapping persists. – Qiang Xu Jul 20 '18 at 19:15
This was precisely my problem - a user .bashrc wasn't calling /etc/bashrc, and so making a mess. – Sobrique Aug 15 '19 at 09:14
@QiangXu I had to resize my window once more, then it worked as expected. – aggregate1166877 Sep 04 '21 at 01:32

phil294 · Answer 3 · 2022-06-09T10:54:52.123

33

I once read somewhere (don't know where anymore) that using \001 and \002 instead of \[ and \] can solve this issue. It did for me.

By the way, defining PS1 does not have to look ugly.

green="\001$(tput setaf 2)\002"
blue="\001$(tput setaf 4)\002"
dim="\001$(tput dim)\002"
reset="\001$(tput sgr0)\002"
PS1="$dim[\t] " # [hh:mm:ss]
PS1+="$green\u@\h" # user@host
PS1+="$blue\w$$reset " # workingdir$
export PS1
unset green blue dim reset

edited Jun 09 '22 at 10:54

answered Jun 02 '18 at 19:06

phil294

905

6

My PS1 calls a command that printf escape sequences causing OP's problem. Only this solution fixes the issue for me. – RickMeasham Jun 04 '18 at 06:47
1

exactly what I was looking for to put in my inpurc set vi-ins-mode-string "${green}I ${white}|" – rambi Dec 20 '21 at 12:25
1

this worked for me and it's pretty elegant as well – Leonardo Kenji Shikida Jun 09 '22 at 02:16

score 14 · Answer 4 · answered Feb 19 '17 at 10:52

14

As mentioned in other answers, non-printable sequences such as \e[0;30m should be wrapped with \[...\].

Additionally (and what I don't see mentioned yet) is it seems that \r\n should be outside of the \[...\] if you have a multi-line prompt. It took me some of trial and error to finally figure that out.

answered Feb 19 '17 at 10:52

Geraden

513

Exactly what I needed. – Lazik Feb 11 '23 at 15:34

score 12 · Answer 5 · answered Dec 19 '13 at 22:51

12

This sounds like an issue with your COLUMNS & LINES environment variable settings. When you resize the window they're typically set automatically by gnome-terminal (I believe) you can force them to be manually set by issuing the command resize.

Example

If I resize my gnome-terminal to 79x17 my variables show up like so:

$ echo $COLUMNS; echo $LINES
79
17

I can force it like so:

$ resize
COLUMNS=79;
LINES=17;
export COLUMNS LINES;

answered Dec 19 '13 at 22:51

slm

369,824

1

Interesting, but doesn't help. – Muricula Dec 19 '13 at 22:57
1

This fixed my issue it was not wrapping lines correctly after I ran the command "screen". Thanks!! – nukeguy May 30 '17 at 20:21
What package does the command resize come from? – till Mar 08 '20 at 12:22
@till - think it's part of X11 - https://kb.iu.edu/d/abwh – slm Mar 09 '20 at 15:40

score 9 · Answer 6 · answered Sep 14 '16 at 00:38

9

To prevent wrapping, you can also increase the number of columns using, e.g.

stty columns 120

answered Sep 14 '16 at 00:38

ishmael

208

1

not a very good idea, it messed up vim brutally – phil294 Sep 23 '18 at 04:53
Use rmam / smam as provided by other answer: https://unix.stackexchange.com/a/558771/140633 – ibuprofen Jan 26 '21 at 10:18

The Godfather · Answer 7 · 2018-09-14T10:19:17.210

6

Also the same issue can be caused by using wide unicode symbols (like from https://stackoverflow.com/a/34812608/1657819). Here is the snippet causing the problem (mind the $Green and $Red are properly escaped color strings):

FancyX='\342\234\227'
Checkmark='\342\234\223'


# Add a bright white exit status for the last command
PS1="$White\$? "
# If it was successful, print a green check mark. Otherwise, print
# a red X.
if [[ $Last_Command == 0 ]]; then
    PS1+="$Green$Checkmark "
else
    PS1+="$Red$FancyX "
fi

Bash cannot calculate the length correctly, so easiest way could be to escape 2 out of three parts of those wide symbols.

FancyX='\[\342\234\]\227'
Checkmark='\[\342\234\]\223'

edited Sep 14 '18 at 10:19

answered Sep 14 '18 at 09:18

The Godfather

341
3
7

Makes sense. What I guess is that bash counts characters. Because the X takes one char but is written as 3, then one needs to enclose 2 of them to fix counting. @blauhirn answer also explains how to do in a function with \001 and \002. – akostadinov Jan 24 '19 at 22:59
FYI, this is how you figure out how to output multi-byte unicode characters in this format: https://stackoverflow.com/a/602924/520567 – akostadinov Jan 25 '19 at 07:36
If you get your prompt set up correctly, you might also see these symptoms if there's a mismatch between bash and your terminal. For example, I had changed my LANG variable from the default of en_US.utf8 to en_US.iso88591 in order to work on some data in the Latin-1 character set, and I had forgotten to change it back when I was done. – Russell Reed May 06 '21 at 21:28

score 3 · Answer 8 · answered Dec 24 '19 at 13:10

3

tput smam

On Ubuntu 19.10 in a Gnome terminal, which has TERM=xterm-256color, this emits the exact escape sequence that makes the terminal wrap lines:

tput smam

You can see what that escape is with:

tput smam | hd

Resetting the terminal state with:

reset

also seems to have the effect of setting tput smam.

The man page:

man terminfo

documents smam and its opposite rmam:

       enter_am_mode   smam   SA   turn on automatic margins
       exit_am_mode    rmam   RA   turn off automatic margins

Note however that certain terminals don't have that capability, e.g. inside tmux we have TERM=screen-265color and smam does not appear on the list of capabilities:

infocmp

and so tput smam doesn't print anything.

I'm not sure how, but QEMU was able to change the line wrap state of tmux while tput wasn't.

answered Dec 24 '19 at 13:10

Ciro Santilli OurBigBook.com

18,092
4
117
102

2

Under tmux and screen, setterm --linewrap=off still works. Probably hard-coded to \033[?7l and \033[?7h without consulting termcap/terminfo? – Beni Cherniavsky-Paskin Oct 21 '20 at 21:22
@BeniCherniavsky-Paskin thanks for this info. I'm going to try it out next time it starts hurting me! :-) Gotta (re)learn where the escape code list is documented. – Ciro Santilli OurBigBook.com Oct 21 '20 at 21:28
@BeniCherniavsky-Paskin OK, Esc[?7l is what it emits according to hd and its name is DECAWM according to http://ascii-table.com/ansi-escape-sequences-vt-100.php – Ciro Santilli OurBigBook.com Oct 21 '20 at 21:32

score 2 · Answer 9 · answered Nov 14 '21 at 22:26

2

I have 2 almost identical Archlinux setups and after I switched one to "powerline" PS1 with Unicode characters I've got the same problem. It turned out that on affected laptop I was missing /etc/locale.conf file

LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_COLLATE=en_US.UTF-8

once I've copied it over, terminal became Unicode-aware and "line overlap" problem went away.

answered Nov 14 '21 at 22:26

al3xxx

21

This answer saved me. I had totally forgotten that I had put LC_ALL=C in my .bashrc. With Starship, this was causing prompt issues. Switching to UTF-8 (which is what I should have used in the FIRST place) fixed my problem. – Craig Kelly Jan 23 '23 at 17:08

score 0 · Answer 10 · answered Feb 11 '21 at 11:14

Thanks to this article, I've got my prompt working very nicely. And when combined with gitprompt (https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh), I get the exact things I want.

PS1_RESET='\001$(tput sgr0)\002'
PS1_ERROR='$(code=${?##0};echo ${code:+\001$(tput setaf 1)\002[${code}]\ })'"$PS1_RESET"
PS1_SHLVL='\001$(tput setaf 4)\002($SHLVL) '"$PS1_RESET"
PS1_DATE='\001$(tput setaf 5)\002\D{%Y-%m-%d %H:%M:%S} '"$PS1_RESET"
PS1_USER='\001$(tput setaf 6)\002\u'"$PS1_RESET"
PS1_AT='\001$(tput sgr0)\002@'"$PS1_RESET"
PS1_HOST='\001$(tput setaf 2)\002\h'"$PS1_RESET"
PS1_COLON='\001$(tput sgr0)\002:'"$PS1_RESET"
PS1_PATH='\001$(tput setaf 3)\002\w'"$PS1_RESET"
PS1_GIT='$(__git_ps1 " (%s)")'"$PS1_RESET"
PS1_PROMPT=' \\$ '
PS1_COMBINED=$PS1_ERROR$PS1_SHLVL$PS1_DATE$PS1_USER$PS1_AT$PS1_HOST$PS1_COLON$PS1_PATH
export PS1="$PS1_COMBINED"
GIT_PS1_COMPRESSSPARSESTATE=
GIT_PS1_DESCRIBE_STYLE=
GIT_PS1_HIDE_IF_PWD_IGNORED=yes
GIT_PS1_OMITSPARSESTATE=
GIT_PS1_SHOWCOLORHINTS=yes
GIT_PS1_SHOWDIRTYSTATE=yes
GIT_PS1_SHOWSTASHSTATE=yes
GIT_PS1_SHOWUNTRACKEDFILES=yes
GIT_PS1_SHOWUPSTREAM="auto"
GIT_PS1_STATESEPARATOR=" "
export PROMPT_COMMAND='__git_ps1 "$PS1_COMBINED" "$PS1_PROMPT"'

score 0 · Answer 11 · answered Dec 05 '23 at 12:40

The question asked is for the Bash shell interpreter, as like many of the other questions on similar topic. None, if not few, point to on how to do it on the Zsh shell interpreter.

\[ ... \] or \001 ... \002 won't work with .zshrc. For Zsh, the special characters are %{ and %}. For example, here is how you would configure your prompt with colors in .zshrc :

promptText="megh$ "
PS1="%{$(tput bold)$(tput setaf 3)%}$promptText%{$(tput sgr0)%}"

Link to documentation

Terminal prompt not wrapping correctly

11 Answers11

Edit:

Example

Linked

Related