Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recently modified my Bash prompt via the $PS1 variable so that I could have color. It is in my .bashrc file:

PS1="\\[\e[0;32m[\h::\W] >>\e[m "

Now if I type something and then have to backspace to clear it the entire prompt disappears. If I hit enter a new one shows up.

Looking at this question regarding the same issue it would appear that I am missing a closing bracket. I don't know where it would go, though.

share|improve this question
Your \\ backslashes escape themselves. Use ' hard quotes and only one \[ – mikeserv Aug 16 '14 at 3:31
Is this what you mean: PS1='\[\e[0;32m[\h::\W] >>\e[m '? If so, it didn't help. If not, I don't understand what you're saying. :( – theillien Aug 16 '14 at 3:34
You need to close the sequence. The \[ means begin non-printing escape sequence in the prompt - it's so readline can keep track of how many chars are drawn on the screen. What about: '\[...\] - I thinks that's how it closes... I'll check man bash... yeah that's right. Try: man bash | grep '^ *\\\[' -A5 – mikeserv Aug 16 '14 at 3:36
No need to check man bash. I changed to this: PS1='\[\e[0;32m[\h::\W] >>\e[\]m '. It doesn't disappear now. Thanks for the input! – theillien Aug 16 '14 at 3:38
@mikeserv If you go ahead and write your comment up as the answer I'll select it. – theillien Aug 16 '14 at 4:03
up vote 7 down vote accepted

At first I thought that the backslashes would self-escape within the double-quotes and that was the problem, but, on second-thought, "\\[" is equivalent to '\[' so this is not the case - it would have worked that way.

But the real problem was that readline did not know how many characters had been drawn to the screen and how many were intercepted as terminal escapes. In fact, it likely thought no prompt had been printed at all because your prompt consisted of what was essentially an open-quoted string.

So, as I noted in the comment, you needed to close the sequence. The \[ means begin non-printing escape sequence in the prompt - it's so readline can keep track of how many chars are drawn on the screen. You also need to end it like:

PS1='\[non-printing terminal escapes here\]' 

man bash 2>/dev/null | grep '^ *\\\[' -A5

\[     begin  a  sequence  of   non-printing
       characters,  which  could  be used to
       embed  a  terminal  control  sequence
       into the prompt
\]     end  a sequence of non-printing char‐
share|improve this answer
Much obliged, Sir! – theillien Aug 16 '14 at 4:37
@theillien: not sure, but I think PS1='\[\e[0;32m[\h::\W] >>\e[\]m ' might not be right. Youu may still be off in the count though you likely won't notice until you start doing some prompt redraws - like for newlines in $PS2 or so. I think this is safer PS1='\[\e[0;32m\][\h::\W] >>\[\e[m\] ' - see how the \e bits are enclosed in the \[...\] quoted portion, but the printing bits - even the bash specific escapes are not enclosed. readline needs to know what bits are intercepted by the terminal - like color escapes - and what bits actually make it on the screen. Hence \[...\] – mikeserv Aug 16 '14 at 4:51
I have seen the newline issue that you mentioned. Instead of continuing a command onto a new line it begins to overwrite the line on which it started. I've replaced it with your suggestion. We'll see if that makes a difference. – theillien Aug 25 '14 at 23:06

Your Answer


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.