Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Something I have noticed in Ubuntu for a long time that has been frustrating to me is when I am typing a command at the command line that gets longer (wider) than the terminal width, instead of wrapping to a new line, it goes back to column 1 on the same line and starts over-writing the beginning of my command line. (It doesn't actually overwrite the actual command, but visually, it is overwriting the text that was displayed).

It's hard to explain without seeing it, but let's say my terminal was 20 characters wide (Mine is more like 120 characters - but for the sake of an example), and I want to echo the English alphabet. What I type is this:

echo abcdefghijklmnopqrstuvwxyz

But what my terminal looks like before I hit the key is:

pqrstuvwxyzghijklmno

When I hit enter, it echos

abcdefghijklmnopqrstuvwxyz

so I know the command was received properly. It just wrapped my typing after the "o" and started over on the same line.

What I would expect to happen, if I typed this command in on a terminal that was only 20 characters wide would be this:

echo abcdefghijklmno
pqrstuvwxyz

Background: I am using bash as my shell, and I have this line in my ~/.bashrc:

set -o vi

to be able to navigate the command line with VI commands. I am currently using Ubuntu 10.10 server, and connecting to the server with Putty.

In any other environment I have worked in, if I type a long command line, it will add a new line underneath the line I am working on when my command gets longer than the terminal width and when I keep typing I can see my command on 2 different lines. But for as long as I can remember using Ubuntu, my long commands only occupy 1 line.

This also happens when I am going back to previous commands in the history (I hit Esc, then 'K' to go back to previous commands) - when I get to a previous command that was longer than the terminal width, the command line gets mangled and I cannot tell where I am at in the command.

The only work-around I have found to see the entire long command is to hit "Esc-V", which opens up the current command in a VI editor.

I don't think I have anything odd in my .bashrc file. I commented out the "set -o vi" line, and I still had the problem.

I downloaded a fresh copy of Putty and didn't make any changes to the configuration - I just typed in my host name to connect, and I still have the problem, so I don't think it's anything with Putty (unless I need to make some config changes)

Has anyone else had this problem, and can anyone think of how to fix it?

Thanks in advance!

Brian

Edit

It was my .bashrc file. I've copied the same profile from machine to machine, and I used special characters in my $PS1 that are somehow throwing it off. I'm now sticking with the standard bash variables for my $PS1.

Thanks to @ændrük for the tip on the .bashrc!

...End Edit...

share|improve this question
1  
Just to be sure the issue isn't caused by your .bashrc file, I'd recommend temporarily replacing it with a copy of /etc/skel/.bashrc. Keep in mind that you'll need to reconnect for the changes to take effect, and be sure to keep a backup of your own .bashrc. –  ændrük Feb 1 '11 at 20:53
1  
Which terminal application are you using ? The behavior you are describing is not usual, certainly not a default. –  João Pinto Feb 1 '11 at 21:17
    
In shells that I've worked in (and in Cisco CLI) you can also type Ctrl-L to redisplay the line you are typing, even if it's offscreen. In your situation, that may still produce the broken output you're talking about, but I'd be curious. –  belacq Feb 1 '11 at 23:26
3  
Feel free to create an "answer" explaining the solution and mark it as accepted. It can seem a little silly, but having a proper answer helps keep the site organized and might more effectively guide others who have similar problems in the future. –  ændrük Feb 2 '11 at 5:07

5 Answers 5

up vote 25 down vote accepted

I guess you have configured your PS1 with colors, right?

Just make sure you have \\[ inside your PS1 quote preceding your color set

For example:

PS1='\\[\e[0;32m\u@\w/:\[\e[m '
share|improve this answer
    
My PS1 was export PS1='^[[96m'$(hostname)'<^[[92m${PWD}^[[96m>^[[97m ' - I've been using that one for a long time - it's KSH compatible... –  BrianH Feb 2 '11 at 16:48
    
Wow. I've been using terminal prompts since forever and never had this problem before. Would have never figured that out. Thanks. –  bchurchill Sep 30 '13 at 21:51
    
using \[ while using simple quotes yields an unintended slash. also, there should be used ] in the end of the magical chars, as noted in the best-voted answer –  Igoru Jul 3 at 21:32

Make sure all non-printable bytes in your PS1 are contained within \[ \]. Otherwise, bash will count them in the length of the prompt. It uses the length of the prompt to determine when to wrap the line.

For example, this line will subtract from the count where your term expects the next line to start:

PS1+='\e[0m'

While this line does not, as it is encased in the counters.

PS1+='\[\e[0m\]'

Wraping the entire line like this will case bad behavior, you need to do this for each instance of invisible characters, otherwise this will also negate the text you WANT to display.

PS1+='\[\e[46m\eHello World[0m\]' #This is bad, do not do this.

If you're using double-quotes you need to double-escape the slashes:

PS1+="\\["

See http://mywiki.wooledge.org/BashFAQ/053

share|improve this answer
    
That's a great explanation of the problem that the accepted answer doesn't provide –  Jamie Cook Oct 2 '13 at 0:41
    
this should be the right answer :) –  Igoru Jul 3 at 21:30
    
this is the correct answer. –  Grady Player Dec 13 at 18:15

I had the same issue with a custom coloured prompt, even though I contained colour codes within \[ and \] delimiters. It turns out that bash has problems echoing colours from inside a function. I ended up just using variables for my prompt, and though my .bashrc is a little less elegant, everything works nicely now.

share|improve this answer

I had a similar issue, and finally found a simple solution.

Add following line in your .bashrc file:

COLUMNS=250

Then log off the current session and re-login to get the desired effect.

share|improve this answer
    
In some cases, such as narrow terminator subdivisions, the problem is not in the promt color characters but just in a wrong COLUMNS value. This answer took me out of a very bothering hole! –  Carles Sala Jan 13 at 13:31

A simple thing to do would be to add the following line before setting the PS1:

stty columns 1000

For example,

stty columns 1000
PS1='\[\e[0;32m\u@\w/:[\e[m '

however this does affect other unix commands like ls and man.

share|improve this answer
    
That works in OSX. –  raskhadafi Jun 26 at 7:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.