I have to use a system that requires login via some Citrix/Windows virtualizations to eventually access a RedHat EL 6 system where I'm experiencing some really weird behavior that the admins haven't been able to fix.

Basically, vi and vim both seem to work fine unless I'm using either inside a screen. Once inside the screen, there are serious redraw issues that occur during inserts if I move outside the initial contents displayed (i.e. moved to end or middle of file that is longer than the screen can show, or I scroll down past the bottom a line or two). When this happens, the -- INSERT -- that is drawn at the bottom of the terminal screen pushes everything up a line. If your edits are minor (i.e. not moving around and making many changes on different lines), it's usually OK, but things are redrawn incorrectly (sometimes additional feedback from vi itself scrolls the previous line up one so you end up with two -- INSERT -- lines, or other text) But, if you move around after an insert, especially if you force the contents of the window to scroll or be drawn completely, it's a total mess. Moving the cursor around to end of line or whatever doesn't follow what is shown on the screen.

To make things a bit more frustrating, this weird system can be accessed in two ways: 1 via a terminal session (through a virtualized IE browser) and 1 via a VNC desktop (through same virtualization). Unfortunately, the VNC desktop is completely unusable for command line because of refresh issues and stuck characters (random characters being repeated hundreds of times). But, despite these problems, vi does work inside screens.

I've dumped the variables from both types of vi sessions to files and they are different, but I don't know vi well enough to know which variables could be the culprit.

FWIW, both are using the same VIM 7.2.411 binary (the issue persists with /bin/vi) and screen 4.00.03 Both are on the same machine

When I submitted a helpdesk ticket, the admins installed a newer version of VIM, which actually made it a lot less severe, but it's still unusable for editing files beyond very minor changes.

  • Not a complete solution, but you can at any time in normal mode use ^L to redraw the screen as a workaround.
    – DopeGhoti
    Apr 13, 2017 at 18:15
  • 1
    I'm that the size values might be incorrect, could you please compare stty size inside and outside screen? Also what are the values of $TERM?
    – phk
    Apr 13, 2017 at 18:32
  • stty size yields same result in screen and outside screen. TERM is screen.linux and linux
    – user632657
    Apr 13, 2017 at 18:46
  • FWIW, the only solution to this was to switch to tmux, which doesn't exhibit the behavior. Admins suspect it's related to the regional server I am using to access the linux servers (through a virtualized IE) filtering out some key information that vi relies on.
    – user632657
    Apr 21, 2017 at 15:14

1 Answer 1


The issue may be that your screen is configured to use the last line of the terminal window as the hardstatus line, and you open a window in your screenrc before configuring the hardstatus line. Does your screen configuration contain something like this?

screen 1
# ...
hardstatus alwayslastline "..."

In this case, the window opened by the screen command in the screenrc doesn't have the correct number of lines configured--it doesn't take into account the line used by the hardstatus line. Other windows should be fine, however (compare the output of stty size in the initial window, opened by the screenrc, and other windows).

I've opened a bug for this issue here. Although it makes some sense in retrospect that the screen command preceding the hardstatus configuration might have this effect, it's pretty unexpected from the user's perspective (many configuration files don't have a notion of sequencing). Also, oddly enough, if you do something like:

screen 1
screen 2
screen 3
# ...
hardstatus alwayslastline "..."

Only window 3 is incorrectly configured.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .