Take the 2-minute tour ×

I'm having an issue using screen and Terminal.app. If I get a bash prompt at the bottom of the screen and I keep typing until the line wraps to the next line, I see the next line, but I do not see the line above this one change.

Here's a visual way of illustrating my problem. The | represents the right hand side of the terminal.

Before. My cursor is after the third 'example' and I'm about to type 'example' a forth time:

$ asdf                        |
bash: asdf: command not found |
$ example example example     |

After. Note how after wrapping, the screen did not scroll, but instead 'ate' the line I was on and began fresh:

$ asdf                        |
bash: asdf: command not found |
ple                           |

What I expected (and what happens without the use of screen) is that the entire screen scrolls down one after the wrap.

bash: asdf: command not found |
$ example example example exam|
ple                           |

Finally, this what happens if I move the cursor on the wrapped line to the beginning of the command line, it eats the previous line:

$ asdf                        |
$ example example example exam|
ple                           |

Any idea what is going on?

share|improve this question
GNOME Terminal and screen 4 wrap as expected over here, FWIW. What version are you running and have you changed any configurations from the default? –  Bernard Sep 25 '09 at 18:23
This happens when connected to two different machines. My debian machine has screen 4 with some custom configurations done to it, and my rhel 5.3 box also has screen 4 with no custom configurations and both boxes exhibit the exact same behavior. –  AlexMax Sep 25 '09 at 18:27
I have the exact same behavior. Another symptom of it (not described above) is that after the previous line is 'eaten', strange things happen with selections. Start selecting with the mouse, and whatever is under the selection will appear correct. Ex: if you were to select the "$ asdf" line in the last example above, it would suddenly change to "bash: asdf: command not found" (which is what the previous line should say.) It's as if the screen just hasn't re-drawn those lines, but should have. It's like it's forgetting to mark those lines as dirty, needing to be re-rendered. –  Eddified Oct 28 '10 at 17:24
At any time it starts to go bad, just select all (COMMAND+A) to make the screen buffer look right. –  Eddified Nov 3 '10 at 20:02
Also, this isn't a problem in iTerm.app –  Eddified Nov 3 '10 at 20:03

3 Answers 3

Success! I tried the suggestion from here:


which is to add:

termcapinfo xterm* ti@:te@

to your .screenrc and restart screen. This changes screen's scrollback behavior to something probably better for my average use case (eg, I can use Terminal's scrollback as long as I stay in the same window), in addition to fixing OP's problem.

Also, I can confirm the problem in 10.7's Terminal.app.

share|improve this answer
Nice detective work! Unfortunately, I am a heavy user of screen's multiple windows, so this won't work for me. –  AlexMax Jun 20 '12 at 18:39

It could be readline's 'horizontal-scroll-mode'. Run the following command:

bind 'set horizontal-scroll-mode off'

and see if your symptoms change. If so, you can set that in ~/.inputrc

share|improve this answer
didn't help it in my case. –  Eddified Oct 28 '10 at 17:26

Go into terminal settings and change the "Declare terminal as:" setting from "xterm-color" to just "xterm". That fixed it for me (but also has the consequence of turning off altscreen :( )

share|improve this answer
I've already configured Terminal.app this way, and it doesn't help me with my issue. horizontal-scroll-mode is off by default according to screen man page, and I don't see anywhere it's set to on. Bummer. Would really like to find a solution to this. –  Tim Harper Nov 2 '11 at 18:00

Your Answer


