Cygwin wraps text back on to the same line, causing text to be overwritten

Question

I have cygwin installed on my Windows 7 box and I have been running into a problem where when I type a command it will occasionally be wrapped back onto the same line, deleting the bash prompt. Here is an example:

The command in question is command "201" (4 lines from the bottom). I included the others for context.

The text of the command I was typing was

git commit -m "Forced LF line endings."

(Note: I am posting this with mostly git commands, but the problem occurs with any command. I have not noticed a pattern yet.)

It jumped to the start of the line and started to overwrite my prompt.

When I push the up arrow (to view the history) the result is even weirder:

(Note the cursor is many characters past the end of the command.) When I try to backspace the cursor from that position, I can only go back this far:

Then when I go up into the history from that backspaced line, I get this:

The command starts from the end of the text that is displayed. (This is consistent for the entire history) But when I go up in the history to the faulty git commit ... it displays as it did before with the overwritten text but when I go past it, it deletes a line of the prompt and displays the previous entry in the history the same way it was doing it before (a la image 2).

When I was creating my PS1 variable I has odd output like this, but I have since closed my brackets and things and don't think that is causing the issue. However if you would like to see my .bash_profile (that sets the PS1) feel free to see it on GitHub. It is really short.

I have tried searching for the issue and can only find a few cygwin email archives about the line wrapping in xterm, but no solutions.

PS: As I was pushing the latest .bash_profile, in order to link it, I ran into the problem again when I typed git add .bash_profile and hit enter, it ran the command but returned the cursor to the start of the same command instead of printing a new prompt. Then when I as writing another commit line, it did the same as the first image, but it blacked out the rest of the line (It wrapped the line, but overwrote the entire line and not just the first few chars.)

Llewellyn

I think this happens because you're not encoding the escape sequences in your prompt properly, so bash is confused about the amount of remaining space on the line. – Aria

Can you please elaborate? How would I fix this? – Llewellyn

Answer 1

See http://manpages.ubuntu.com/manpages/lucid/man1/bash.1.html#contenttoc26:

\[

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 characters

If you don't enclose non-printing characters (e.g. color sequences) in your prompt with these their length is counted as part of the prompt's length, eventually resulting in the symptoms that you describe.

Hellenism

I tested it on my new Mac's terminal and it seems to work fine. I am going to see if it is the same on other terminals as well, but for now, you get the accepted answer. It seems the color codes need to start with \e[ and then be closed with \]. My vim syntax highlighting did not match those as a pair so I added too many. – Llewellyn

I ended up using bash's $(tput setaf #) to set the colors. It seems to work a lot better than the braces. – Llewellyn

oh god, yes, I've had this problem for years and never knew why! (accidentally placed \W inside of \[ ... \]) – Negation

Answer 2

It doesn't occur frequently to me. When it does, I just type in 'kill -WINCH $$' into the cygwin terminal and it fixes the problem. link to source

Principled