How do I get long command lines to wrap to the next line?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







103















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?



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.

    – belacqua
    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











  • As per this answer on serverfault, use tput smam

    – Samveen
    Oct 23 '17 at 10:37


















103















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?



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.

    – belacqua
    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











  • As per this answer on serverfault, use tput smam

    – Samveen
    Oct 23 '17 at 10:37














103












103








103


40






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?



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
















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?



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...







command-line bash






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 19 '15 at 9:31









Hugo

14410




14410










asked Feb 1 '11 at 20:17









BrianHBrianH

618278




618278








  • 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.

    – belacqua
    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











  • As per this answer on serverfault, use tput smam

    – Samveen
    Oct 23 '17 at 10:37














  • 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.

    – belacqua
    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











  • As per this answer on serverfault, use tput smam

    – Samveen
    Oct 23 '17 at 10:37








1




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





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




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





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.

– belacqua
Feb 1 '11 at 23:26





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.

– belacqua
Feb 1 '11 at 23:26




3




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





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













As per this answer on serverfault, use tput smam

– Samveen
Oct 23 '17 at 10:37





As per this answer on serverfault, use tput smam

– Samveen
Oct 23 '17 at 10:37










8 Answers
8






active

oldest

votes


















128














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, here bash counts the prompt as 19 columns wide, while the prompt displayed by the terminal is only 10 columns wide (My prompt written in cyan, and > written in default color):



PS1='e[36mMy prompte[0m>'         # bash count: 19, actual: 10


while here it only counts the prompt as 10 columns wide because it ignores the bytes between the special [ and ] escapes:



PS1='[e[36m]My prompt[e[0m]>' # bash count: 10, actual: 10


For good practice though, use tput to generate the terminal escapes rather than hard coding them:



cyan=$(tput setaf 6) # e[36m
reset=$(tput sgr0) # e[0m
PS1='[$cyan]My prompt[$reset]>'


See http://mywiki.wooledge.org/BashFAQ/053, and also http://wiki.bash-hackers.org/scripting/terminalcodes for more on tput.






share|improve this answer





















  • 3





    That's a great explanation of the problem that the accepted answer doesn't provide

    – Jamie Cook
    Oct 2 '13 at 0:41











  • In the last line of code PS1='...' : why don't single quotes prevent $cyan and $reset from substitution?

    – andrybak
    Nov 15 '15 at 13:52






  • 2





    @andrybak, they do prevent $cyan and $reset from being substituted, but PS1 is evaluated every time the prompt is printed. You can see this by trying PS1='$var> ' and then give var various values and see how the prompt change. Then try PS1="$var> " and notice that the prompt remains static; $var got expanded during assignment, not every time PS1 is evaluated.

    – geirha
    Nov 16 '15 at 19:52








  • 1





    This is amazing. Thanks so much for posting this! It makes escaping the square brackets much easier and more readable.

    – phyatt
    Dec 1 '15 at 20:41











  • How I do make this work PS1=${PS1}"e]2;$@a" . I tried PS1=${PS1}"[e]2;]$@[a]"

    – Ramana Reddy
    Jul 28 '16 at 10:27





















58














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;32mu@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






  • 2





    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






  • 3





    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

    – igorsantos07
    Jul 3 '14 at 21:32






  • 2





    -1 Doesn't work. You need to wrap the non-printing section with [ at the start and ] at the end.

    – wjandrea
    Oct 29 '17 at 0:52











  • @igorsantos07 The double-backslash in \[ was a typo caused by an edit. I've fixed it.

    – wjandrea
    Oct 29 '17 at 0:53



















11














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



Add following line in your .bashrc file:



COLUMNS=250


Then type source ~/.bashrc 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 '14 at 13:31






  • 1





    Logging off is unnecessary. Do source .bashrc. Your prompt will update immediately

    – Sergiy Kolodyazhnyy
    Aug 17 '15 at 1:24






  • 1





    I found that since I didn't have shopt setwinsize set for my bash, so it wasn't updating COLUMNS right, see unix.stackexchange.com/a/167911/8337

    – rogerdpack
    Sep 11 '15 at 22:11






  • 1





    I did export COLUMNS=250 followed by export TERM=xterm and it was happy.

    – Philip Kearns
    Aug 2 '16 at 14:18



















5














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


























  • If anyone's still reading this, it is actually possible to escape colors in a function. See this answer on the linked question.

    – wjandrea
    Oct 29 '17 at 1:20



















2














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;32mu@w/:[e[m '


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






share|improve this answer





















  • 1





    That works in OSX.

    – raskhadafi
    Jun 26 '14 at 7:12






  • 4





    This also affects vim badly. Please don't use this.

    – justhalf
    Dec 28 '15 at 7:21



















0














I had this problem when connected in tmux. The problem was that I had an ipython session in the background (ctrl + z) and that somehow broke line wrapping. As soon as I terminated it (fg, ctrl+d+d) my terminal started working properly



So check for any stopped interactive prompts.






share|improve this answer































    0














    So I just had the same issue with a slight twist on it and I thought I would share my solution too, just to add my little nuance :D



    My initial PS1 was



    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$"


    The problem I had was that I was trying to change my terminal title as well as the command prompt. The way I did this was by adding [33]0;]Titlea to the PS1 variable.



    So now my PS1 was:



    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[33]0;]Titlea"


    This messed up the line wrapping for me. I finally figured out that bash doesn't seem to like having a at the end. To circumvent this, I put the title in a variable, which seemed to fix it.



    TITLE="33]0;Titlea"
    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[$TITLE]"





    share|improve this answer































      0














      [ and ] didn't work for me. I guess there was something different about how I was generating the prompt (from an external program), or because my prompt was "dynamic".



      After reading this I found that you can actually escape the color codes with the 0x01 and 0x02 bytes.



      e.g. I'm using a special version of Chalk and I wrap the colors using this:



      const Chalk = require('@nasc/chalk');

      const chalk = new Chalk.constructor({
      wrapper: {
      pre: '1',
      post: '2',
      }
      });





      share|improve this answer
























        Your Answer








        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "89"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: true,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: 10,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });














        draft saved

        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f24358%2fhow-do-i-get-long-command-lines-to-wrap-to-the-next-line%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        8 Answers
        8






        active

        oldest

        votes








        8 Answers
        8






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        128














        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, here bash counts the prompt as 19 columns wide, while the prompt displayed by the terminal is only 10 columns wide (My prompt written in cyan, and > written in default color):



        PS1='e[36mMy prompte[0m>'         # bash count: 19, actual: 10


        while here it only counts the prompt as 10 columns wide because it ignores the bytes between the special [ and ] escapes:



        PS1='[e[36m]My prompt[e[0m]>' # bash count: 10, actual: 10


        For good practice though, use tput to generate the terminal escapes rather than hard coding them:



        cyan=$(tput setaf 6) # e[36m
        reset=$(tput sgr0) # e[0m
        PS1='[$cyan]My prompt[$reset]>'


        See http://mywiki.wooledge.org/BashFAQ/053, and also http://wiki.bash-hackers.org/scripting/terminalcodes for more on tput.






        share|improve this answer





















        • 3





          That's a great explanation of the problem that the accepted answer doesn't provide

          – Jamie Cook
          Oct 2 '13 at 0:41











        • In the last line of code PS1='...' : why don't single quotes prevent $cyan and $reset from substitution?

          – andrybak
          Nov 15 '15 at 13:52






        • 2





          @andrybak, they do prevent $cyan and $reset from being substituted, but PS1 is evaluated every time the prompt is printed. You can see this by trying PS1='$var> ' and then give var various values and see how the prompt change. Then try PS1="$var> " and notice that the prompt remains static; $var got expanded during assignment, not every time PS1 is evaluated.

          – geirha
          Nov 16 '15 at 19:52








        • 1





          This is amazing. Thanks so much for posting this! It makes escaping the square brackets much easier and more readable.

          – phyatt
          Dec 1 '15 at 20:41











        • How I do make this work PS1=${PS1}"e]2;$@a" . I tried PS1=${PS1}"[e]2;]$@[a]"

          – Ramana Reddy
          Jul 28 '16 at 10:27


















        128














        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, here bash counts the prompt as 19 columns wide, while the prompt displayed by the terminal is only 10 columns wide (My prompt written in cyan, and > written in default color):



        PS1='e[36mMy prompte[0m>'         # bash count: 19, actual: 10


        while here it only counts the prompt as 10 columns wide because it ignores the bytes between the special [ and ] escapes:



        PS1='[e[36m]My prompt[e[0m]>' # bash count: 10, actual: 10


        For good practice though, use tput to generate the terminal escapes rather than hard coding them:



        cyan=$(tput setaf 6) # e[36m
        reset=$(tput sgr0) # e[0m
        PS1='[$cyan]My prompt[$reset]>'


        See http://mywiki.wooledge.org/BashFAQ/053, and also http://wiki.bash-hackers.org/scripting/terminalcodes for more on tput.






        share|improve this answer





















        • 3





          That's a great explanation of the problem that the accepted answer doesn't provide

          – Jamie Cook
          Oct 2 '13 at 0:41











        • In the last line of code PS1='...' : why don't single quotes prevent $cyan and $reset from substitution?

          – andrybak
          Nov 15 '15 at 13:52






        • 2





          @andrybak, they do prevent $cyan and $reset from being substituted, but PS1 is evaluated every time the prompt is printed. You can see this by trying PS1='$var> ' and then give var various values and see how the prompt change. Then try PS1="$var> " and notice that the prompt remains static; $var got expanded during assignment, not every time PS1 is evaluated.

          – geirha
          Nov 16 '15 at 19:52








        • 1





          This is amazing. Thanks so much for posting this! It makes escaping the square brackets much easier and more readable.

          – phyatt
          Dec 1 '15 at 20:41











        • How I do make this work PS1=${PS1}"e]2;$@a" . I tried PS1=${PS1}"[e]2;]$@[a]"

          – Ramana Reddy
          Jul 28 '16 at 10:27
















        128












        128








        128







        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, here bash counts the prompt as 19 columns wide, while the prompt displayed by the terminal is only 10 columns wide (My prompt written in cyan, and > written in default color):



        PS1='e[36mMy prompte[0m>'         # bash count: 19, actual: 10


        while here it only counts the prompt as 10 columns wide because it ignores the bytes between the special [ and ] escapes:



        PS1='[e[36m]My prompt[e[0m]>' # bash count: 10, actual: 10


        For good practice though, use tput to generate the terminal escapes rather than hard coding them:



        cyan=$(tput setaf 6) # e[36m
        reset=$(tput sgr0) # e[0m
        PS1='[$cyan]My prompt[$reset]>'


        See http://mywiki.wooledge.org/BashFAQ/053, and also http://wiki.bash-hackers.org/scripting/terminalcodes for more on tput.






        share|improve this answer















        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, here bash counts the prompt as 19 columns wide, while the prompt displayed by the terminal is only 10 columns wide (My prompt written in cyan, and > written in default color):



        PS1='e[36mMy prompte[0m>'         # bash count: 19, actual: 10


        while here it only counts the prompt as 10 columns wide because it ignores the bytes between the special [ and ] escapes:



        PS1='[e[36m]My prompt[e[0m]>' # bash count: 10, actual: 10


        For good practice though, use tput to generate the terminal escapes rather than hard coding them:



        cyan=$(tput setaf 6) # e[36m
        reset=$(tput sgr0) # e[0m
        PS1='[$cyan]My prompt[$reset]>'


        See http://mywiki.wooledge.org/BashFAQ/053, and also http://wiki.bash-hackers.org/scripting/terminalcodes for more on tput.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 31 '15 at 10:22

























        answered Feb 2 '11 at 8:00









        geirhageirha

        31.7k95860




        31.7k95860








        • 3





          That's a great explanation of the problem that the accepted answer doesn't provide

          – Jamie Cook
          Oct 2 '13 at 0:41











        • In the last line of code PS1='...' : why don't single quotes prevent $cyan and $reset from substitution?

          – andrybak
          Nov 15 '15 at 13:52






        • 2





          @andrybak, they do prevent $cyan and $reset from being substituted, but PS1 is evaluated every time the prompt is printed. You can see this by trying PS1='$var> ' and then give var various values and see how the prompt change. Then try PS1="$var> " and notice that the prompt remains static; $var got expanded during assignment, not every time PS1 is evaluated.

          – geirha
          Nov 16 '15 at 19:52








        • 1





          This is amazing. Thanks so much for posting this! It makes escaping the square brackets much easier and more readable.

          – phyatt
          Dec 1 '15 at 20:41











        • How I do make this work PS1=${PS1}"e]2;$@a" . I tried PS1=${PS1}"[e]2;]$@[a]"

          – Ramana Reddy
          Jul 28 '16 at 10:27
















        • 3





          That's a great explanation of the problem that the accepted answer doesn't provide

          – Jamie Cook
          Oct 2 '13 at 0:41











        • In the last line of code PS1='...' : why don't single quotes prevent $cyan and $reset from substitution?

          – andrybak
          Nov 15 '15 at 13:52






        • 2





          @andrybak, they do prevent $cyan and $reset from being substituted, but PS1 is evaluated every time the prompt is printed. You can see this by trying PS1='$var> ' and then give var various values and see how the prompt change. Then try PS1="$var> " and notice that the prompt remains static; $var got expanded during assignment, not every time PS1 is evaluated.

          – geirha
          Nov 16 '15 at 19:52








        • 1





          This is amazing. Thanks so much for posting this! It makes escaping the square brackets much easier and more readable.

          – phyatt
          Dec 1 '15 at 20:41











        • How I do make this work PS1=${PS1}"e]2;$@a" . I tried PS1=${PS1}"[e]2;]$@[a]"

          – Ramana Reddy
          Jul 28 '16 at 10:27










        3




        3





        That's a great explanation of the problem that the accepted answer doesn't provide

        – Jamie Cook
        Oct 2 '13 at 0:41





        That's a great explanation of the problem that the accepted answer doesn't provide

        – Jamie Cook
        Oct 2 '13 at 0:41













        In the last line of code PS1='...' : why don't single quotes prevent $cyan and $reset from substitution?

        – andrybak
        Nov 15 '15 at 13:52





        In the last line of code PS1='...' : why don't single quotes prevent $cyan and $reset from substitution?

        – andrybak
        Nov 15 '15 at 13:52




        2




        2





        @andrybak, they do prevent $cyan and $reset from being substituted, but PS1 is evaluated every time the prompt is printed. You can see this by trying PS1='$var> ' and then give var various values and see how the prompt change. Then try PS1="$var> " and notice that the prompt remains static; $var got expanded during assignment, not every time PS1 is evaluated.

        – geirha
        Nov 16 '15 at 19:52







        @andrybak, they do prevent $cyan and $reset from being substituted, but PS1 is evaluated every time the prompt is printed. You can see this by trying PS1='$var> ' and then give var various values and see how the prompt change. Then try PS1="$var> " and notice that the prompt remains static; $var got expanded during assignment, not every time PS1 is evaluated.

        – geirha
        Nov 16 '15 at 19:52






        1




        1





        This is amazing. Thanks so much for posting this! It makes escaping the square brackets much easier and more readable.

        – phyatt
        Dec 1 '15 at 20:41





        This is amazing. Thanks so much for posting this! It makes escaping the square brackets much easier and more readable.

        – phyatt
        Dec 1 '15 at 20:41













        How I do make this work PS1=${PS1}"e]2;$@a" . I tried PS1=${PS1}"[e]2;]$@[a]"

        – Ramana Reddy
        Jul 28 '16 at 10:27







        How I do make this work PS1=${PS1}"e]2;$@a" . I tried PS1=${PS1}"[e]2;]$@[a]"

        – Ramana Reddy
        Jul 28 '16 at 10:27















        58














        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;32mu@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






        • 2





          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






        • 3





          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

          – igorsantos07
          Jul 3 '14 at 21:32






        • 2





          -1 Doesn't work. You need to wrap the non-printing section with [ at the start and ] at the end.

          – wjandrea
          Oct 29 '17 at 0:52











        • @igorsantos07 The double-backslash in \[ was a typo caused by an edit. I've fixed it.

          – wjandrea
          Oct 29 '17 at 0:53
















        58














        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;32mu@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






        • 2





          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






        • 3





          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

          – igorsantos07
          Jul 3 '14 at 21:32






        • 2





          -1 Doesn't work. You need to wrap the non-printing section with [ at the start and ] at the end.

          – wjandrea
          Oct 29 '17 at 0:52











        • @igorsantos07 The double-backslash in \[ was a typo caused by an edit. I've fixed it.

          – wjandrea
          Oct 29 '17 at 0:53














        58












        58








        58







        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;32mu@w/:[e[m '





        share|improve this answer















        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;32mu@w/:[e[m '






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Oct 29 '17 at 0:52









        wjandrea

        9,57142765




        9,57142765










        answered Feb 2 '11 at 7:06







        user10070




















        • 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






        • 2





          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






        • 3





          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

          – igorsantos07
          Jul 3 '14 at 21:32






        • 2





          -1 Doesn't work. You need to wrap the non-printing section with [ at the start and ] at the end.

          – wjandrea
          Oct 29 '17 at 0:52











        • @igorsantos07 The double-backslash in \[ was a typo caused by an edit. I've fixed it.

          – wjandrea
          Oct 29 '17 at 0:53



















        • 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






        • 2





          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






        • 3





          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

          – igorsantos07
          Jul 3 '14 at 21:32






        • 2





          -1 Doesn't work. You need to wrap the non-printing section with [ at the start and ] at the end.

          – wjandrea
          Oct 29 '17 at 0:52











        • @igorsantos07 The double-backslash in \[ was a typo caused by an edit. I've fixed it.

          – wjandrea
          Oct 29 '17 at 0:53

















        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





        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




        2




        2





        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





        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




        3




        3





        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

        – igorsantos07
        Jul 3 '14 at 21:32





        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

        – igorsantos07
        Jul 3 '14 at 21:32




        2




        2





        -1 Doesn't work. You need to wrap the non-printing section with [ at the start and ] at the end.

        – wjandrea
        Oct 29 '17 at 0:52





        -1 Doesn't work. You need to wrap the non-printing section with [ at the start and ] at the end.

        – wjandrea
        Oct 29 '17 at 0:52













        @igorsantos07 The double-backslash in \[ was a typo caused by an edit. I've fixed it.

        – wjandrea
        Oct 29 '17 at 0:53





        @igorsantos07 The double-backslash in \[ was a typo caused by an edit. I've fixed it.

        – wjandrea
        Oct 29 '17 at 0:53











        11














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



        Add following line in your .bashrc file:



        COLUMNS=250


        Then type source ~/.bashrc 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 '14 at 13:31






        • 1





          Logging off is unnecessary. Do source .bashrc. Your prompt will update immediately

          – Sergiy Kolodyazhnyy
          Aug 17 '15 at 1:24






        • 1





          I found that since I didn't have shopt setwinsize set for my bash, so it wasn't updating COLUMNS right, see unix.stackexchange.com/a/167911/8337

          – rogerdpack
          Sep 11 '15 at 22:11






        • 1





          I did export COLUMNS=250 followed by export TERM=xterm and it was happy.

          – Philip Kearns
          Aug 2 '16 at 14:18
















        11














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



        Add following line in your .bashrc file:



        COLUMNS=250


        Then type source ~/.bashrc 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 '14 at 13:31






        • 1





          Logging off is unnecessary. Do source .bashrc. Your prompt will update immediately

          – Sergiy Kolodyazhnyy
          Aug 17 '15 at 1:24






        • 1





          I found that since I didn't have shopt setwinsize set for my bash, so it wasn't updating COLUMNS right, see unix.stackexchange.com/a/167911/8337

          – rogerdpack
          Sep 11 '15 at 22:11






        • 1





          I did export COLUMNS=250 followed by export TERM=xterm and it was happy.

          – Philip Kearns
          Aug 2 '16 at 14:18














        11












        11








        11







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



        Add following line in your .bashrc file:



        COLUMNS=250


        Then type source ~/.bashrc to get the desired effect.






        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 type source ~/.bashrc to get the desired effect.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 19 '16 at 20:58









        cat

        9381338




        9381338










        answered Apr 17 '12 at 10:58









        DeboshreeDeboshree

        11912




        11912













        • 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 '14 at 13:31






        • 1





          Logging off is unnecessary. Do source .bashrc. Your prompt will update immediately

          – Sergiy Kolodyazhnyy
          Aug 17 '15 at 1:24






        • 1





          I found that since I didn't have shopt setwinsize set for my bash, so it wasn't updating COLUMNS right, see unix.stackexchange.com/a/167911/8337

          – rogerdpack
          Sep 11 '15 at 22:11






        • 1





          I did export COLUMNS=250 followed by export TERM=xterm and it was happy.

          – Philip Kearns
          Aug 2 '16 at 14:18



















        • 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 '14 at 13:31






        • 1





          Logging off is unnecessary. Do source .bashrc. Your prompt will update immediately

          – Sergiy Kolodyazhnyy
          Aug 17 '15 at 1:24






        • 1





          I found that since I didn't have shopt setwinsize set for my bash, so it wasn't updating COLUMNS right, see unix.stackexchange.com/a/167911/8337

          – rogerdpack
          Sep 11 '15 at 22:11






        • 1





          I did export COLUMNS=250 followed by export TERM=xterm and it was happy.

          – Philip Kearns
          Aug 2 '16 at 14:18

















        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 '14 at 13:31





        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 '14 at 13:31




        1




        1





        Logging off is unnecessary. Do source .bashrc. Your prompt will update immediately

        – Sergiy Kolodyazhnyy
        Aug 17 '15 at 1:24





        Logging off is unnecessary. Do source .bashrc. Your prompt will update immediately

        – Sergiy Kolodyazhnyy
        Aug 17 '15 at 1:24




        1




        1





        I found that since I didn't have shopt setwinsize set for my bash, so it wasn't updating COLUMNS right, see unix.stackexchange.com/a/167911/8337

        – rogerdpack
        Sep 11 '15 at 22:11





        I found that since I didn't have shopt setwinsize set for my bash, so it wasn't updating COLUMNS right, see unix.stackexchange.com/a/167911/8337

        – rogerdpack
        Sep 11 '15 at 22:11




        1




        1





        I did export COLUMNS=250 followed by export TERM=xterm and it was happy.

        – Philip Kearns
        Aug 2 '16 at 14:18





        I did export COLUMNS=250 followed by export TERM=xterm and it was happy.

        – Philip Kearns
        Aug 2 '16 at 14:18











        5














        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


























        • If anyone's still reading this, it is actually possible to escape colors in a function. See this answer on the linked question.

          – wjandrea
          Oct 29 '17 at 1:20
















        5














        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


























        • If anyone's still reading this, it is actually possible to escape colors in a function. See this answer on the linked question.

          – wjandrea
          Oct 29 '17 at 1:20














        5












        5








        5







        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 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














        share|improve this answer



        share|improve this answer








        edited May 23 '17 at 12:39









        Community

        1




        1










        answered May 6 '12 at 4:20









        reentimreentim

        5111




        5111













        • If anyone's still reading this, it is actually possible to escape colors in a function. See this answer on the linked question.

          – wjandrea
          Oct 29 '17 at 1:20



















        • If anyone's still reading this, it is actually possible to escape colors in a function. See this answer on the linked question.

          – wjandrea
          Oct 29 '17 at 1:20

















        If anyone's still reading this, it is actually possible to escape colors in a function. See this answer on the linked question.

        – wjandrea
        Oct 29 '17 at 1:20





        If anyone's still reading this, it is actually possible to escape colors in a function. See this answer on the linked question.

        – wjandrea
        Oct 29 '17 at 1:20











        2














        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;32mu@w/:[e[m '


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






        share|improve this answer





















        • 1





          That works in OSX.

          – raskhadafi
          Jun 26 '14 at 7:12






        • 4





          This also affects vim badly. Please don't use this.

          – justhalf
          Dec 28 '15 at 7:21
















        2














        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;32mu@w/:[e[m '


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






        share|improve this answer





















        • 1





          That works in OSX.

          – raskhadafi
          Jun 26 '14 at 7:12






        • 4





          This also affects vim badly. Please don't use this.

          – justhalf
          Dec 28 '15 at 7:21














        2












        2








        2







        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;32mu@w/:[e[m '


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






        share|improve this answer















        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;32mu@w/:[e[m '


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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited May 24 '13 at 21:31









        Community

        1




        1










        answered Feb 12 '13 at 15:27









        GennadyGennady

        391




        391








        • 1





          That works in OSX.

          – raskhadafi
          Jun 26 '14 at 7:12






        • 4





          This also affects vim badly. Please don't use this.

          – justhalf
          Dec 28 '15 at 7:21














        • 1





          That works in OSX.

          – raskhadafi
          Jun 26 '14 at 7:12






        • 4





          This also affects vim badly. Please don't use this.

          – justhalf
          Dec 28 '15 at 7:21








        1




        1





        That works in OSX.

        – raskhadafi
        Jun 26 '14 at 7:12





        That works in OSX.

        – raskhadafi
        Jun 26 '14 at 7:12




        4




        4





        This also affects vim badly. Please don't use this.

        – justhalf
        Dec 28 '15 at 7:21





        This also affects vim badly. Please don't use this.

        – justhalf
        Dec 28 '15 at 7:21











        0














        I had this problem when connected in tmux. The problem was that I had an ipython session in the background (ctrl + z) and that somehow broke line wrapping. As soon as I terminated it (fg, ctrl+d+d) my terminal started working properly



        So check for any stopped interactive prompts.






        share|improve this answer




























          0














          I had this problem when connected in tmux. The problem was that I had an ipython session in the background (ctrl + z) and that somehow broke line wrapping. As soon as I terminated it (fg, ctrl+d+d) my terminal started working properly



          So check for any stopped interactive prompts.






          share|improve this answer


























            0












            0








            0







            I had this problem when connected in tmux. The problem was that I had an ipython session in the background (ctrl + z) and that somehow broke line wrapping. As soon as I terminated it (fg, ctrl+d+d) my terminal started working properly



            So check for any stopped interactive prompts.






            share|improve this answer













            I had this problem when connected in tmux. The problem was that I had an ipython session in the background (ctrl + z) and that somehow broke line wrapping. As soon as I terminated it (fg, ctrl+d+d) my terminal started working properly



            So check for any stopped interactive prompts.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Apr 7 '17 at 20:39









            Ciprian TomoiagăCiprian Tomoiagă

            48129




            48129























                0














                So I just had the same issue with a slight twist on it and I thought I would share my solution too, just to add my little nuance :D



                My initial PS1 was



                PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$"


                The problem I had was that I was trying to change my terminal title as well as the command prompt. The way I did this was by adding [33]0;]Titlea to the PS1 variable.



                So now my PS1 was:



                PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[33]0;]Titlea"


                This messed up the line wrapping for me. I finally figured out that bash doesn't seem to like having a at the end. To circumvent this, I put the title in a variable, which seemed to fix it.



                TITLE="33]0;Titlea"
                PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[$TITLE]"





                share|improve this answer




























                  0














                  So I just had the same issue with a slight twist on it and I thought I would share my solution too, just to add my little nuance :D



                  My initial PS1 was



                  PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$"


                  The problem I had was that I was trying to change my terminal title as well as the command prompt. The way I did this was by adding [33]0;]Titlea to the PS1 variable.



                  So now my PS1 was:



                  PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[33]0;]Titlea"


                  This messed up the line wrapping for me. I finally figured out that bash doesn't seem to like having a at the end. To circumvent this, I put the title in a variable, which seemed to fix it.



                  TITLE="33]0;Titlea"
                  PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[$TITLE]"





                  share|improve this answer


























                    0












                    0








                    0







                    So I just had the same issue with a slight twist on it and I thought I would share my solution too, just to add my little nuance :D



                    My initial PS1 was



                    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$"


                    The problem I had was that I was trying to change my terminal title as well as the command prompt. The way I did this was by adding [33]0;]Titlea to the PS1 variable.



                    So now my PS1 was:



                    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[33]0;]Titlea"


                    This messed up the line wrapping for me. I finally figured out that bash doesn't seem to like having a at the end. To circumvent this, I put the title in a variable, which seemed to fix it.



                    TITLE="33]0;Titlea"
                    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[$TITLE]"





                    share|improve this answer













                    So I just had the same issue with a slight twist on it and I thought I would share my solution too, just to add my little nuance :D



                    My initial PS1 was



                    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$"


                    The problem I had was that I was trying to change my terminal title as well as the command prompt. The way I did this was by adding [33]0;]Titlea to the PS1 variable.



                    So now my PS1 was:



                    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[33]0;]Titlea"


                    This messed up the line wrapping for me. I finally figured out that bash doesn't seem to like having a at the end. To circumvent this, I put the title in a variable, which seemed to fix it.



                    TITLE="33]0;Titlea"
                    PS1="[33[01;32m]u[33[00m]:[33[01;34m]w[33[00m]$[$TITLE]"






                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Feb 25 at 9:49









                    Ciarán J. HagenCiarán J. Hagen

                    86




                    86























                        0














                        [ and ] didn't work for me. I guess there was something different about how I was generating the prompt (from an external program), or because my prompt was "dynamic".



                        After reading this I found that you can actually escape the color codes with the 0x01 and 0x02 bytes.



                        e.g. I'm using a special version of Chalk and I wrap the colors using this:



                        const Chalk = require('@nasc/chalk');

                        const chalk = new Chalk.constructor({
                        wrapper: {
                        pre: '1',
                        post: '2',
                        }
                        });





                        share|improve this answer




























                          0














                          [ and ] didn't work for me. I guess there was something different about how I was generating the prompt (from an external program), or because my prompt was "dynamic".



                          After reading this I found that you can actually escape the color codes with the 0x01 and 0x02 bytes.



                          e.g. I'm using a special version of Chalk and I wrap the colors using this:



                          const Chalk = require('@nasc/chalk');

                          const chalk = new Chalk.constructor({
                          wrapper: {
                          pre: '1',
                          post: '2',
                          }
                          });





                          share|improve this answer


























                            0












                            0








                            0







                            [ and ] didn't work for me. I guess there was something different about how I was generating the prompt (from an external program), or because my prompt was "dynamic".



                            After reading this I found that you can actually escape the color codes with the 0x01 and 0x02 bytes.



                            e.g. I'm using a special version of Chalk and I wrap the colors using this:



                            const Chalk = require('@nasc/chalk');

                            const chalk = new Chalk.constructor({
                            wrapper: {
                            pre: '1',
                            post: '2',
                            }
                            });





                            share|improve this answer













                            [ and ] didn't work for me. I guess there was something different about how I was generating the prompt (from an external program), or because my prompt was "dynamic".



                            After reading this I found that you can actually escape the color codes with the 0x01 and 0x02 bytes.



                            e.g. I'm using a special version of Chalk and I wrap the colors using this:



                            const Chalk = require('@nasc/chalk');

                            const chalk = new Chalk.constructor({
                            wrapper: {
                            pre: '1',
                            post: '2',
                            }
                            });






                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Mar 7 at 18:22









                            mpenmpen

                            83821122




                            83821122






























                                draft saved

                                draft discarded




















































                                Thanks for contributing an answer to Ask Ubuntu!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f24358%2fhow-do-i-get-long-command-lines-to-wrap-to-the-next-line%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

                                ComboBox Display Member on multiple fields

                                Is it possible to collect Nectar points via Trainline?