Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

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

When running vim under GNU screen, I'm finding that combinations of CTRL with the arrow and Pg* keys don't work as expected.

I'm using the Ubuntu 10.10 vim-gnome package.

On a different machine, also running Ubuntu, this did work without problems; unfortunately I don't have that configuration available to me now.

There is a related question here: How to fix Ctrl + arrows in Vim?

However, the suggested solution there is to remap vim's keybindings to work with the terminal emulator, in that case PuTTY. I don't recall doing anything of the sort, and suspect that there is a screen configuration option which will resolve this issue.

There's also a thread on the gnu-screen mailing list which suggests that running vim via $ TERM=xterm vim is an appropriate fix or workaround. This does work, but I'm a bit concerned that there might be side effects. It also doesn't sound familiar enough to be the solution I set up on the other machine (if a solution was necessary).

share|improve this question
+1 - I was having the same problem and - as you suggested - adding term xterm to my ~/.screenrc file fixed it for me. Thanks again! – Justin Ethier Feb 24 '11 at 18:59

As intuited stated in his update, adding term xterm to the ~/.screenrc file seems to fix this problem.

share|improve this answer
Well.. yes, but I'm holding out for some sort of explanation as to why screen doesn't just propagate the $TERM environment variable instead of overriding it with "screen". Presumably there are some circumstances where it's important to have $TERM == screen. – intuited Feb 26 '11 at 4:56
@intuited: The reason Screen sets TERM=screen is that applications running inside are communicating inside a Screen terminal: the control sequences they send and receive are those of Screen, not those of whatever terminal Screen itself is being displayed. Since you can detach a Screen session and reattach it to a different type of terminal, this layer of indirection is necessary. – Gilles Mar 26 '11 at 12:31
@Gilles: Thanks, I suspected something like that. What sorts of problems could arise from resetting it to xterm? – intuited Mar 26 '11 at 20:10
Not much, because xterm and screen are mostly compatible. But each has a few capabilities that the other one doesn't, and if you lie to applications, they might use a capability that doesn't actually work. Compare the output of infocmp screen and infocmp xterm, and the screen escape sequences with the xterm escape sequences. I don't have a breakdown to offer; most applications won't mind, but a few might behave annoyingly. – Gilles Mar 27 '11 at 17:32

There are a couple of other ways to set the terminal which work in running processes:

  • In a running screen instance, pressing ^A-: and issuing the command term xterm will cause newly opened screens under that instance to start with their $TERM environment variable set to xterm; this will in turn propagate to invoked vim instances. These vim instances will display proper behaviour with regard to CTRL-combos; I've not yet discovered any side effects of this strategy. This command does not affect existing screens. This command can of course be used in a ~/.screenrc file, so it's possible that this method was used on the other machine.

  • In a running vim instance, the command set term=xterm will make CTRL-combos work in that vim instance. This has the side effect of disconnecting the X clipboard (i.e. @* and @+) for reasons that I do not yet understand. Interestingly, the clipboard side effect also happens when the command :set term=screen is executed in a vim instance started with $TERM=xterm.

share|improve this answer
This answer was taken from the OP's updates. All I did was to reformat and reword a little bit. – phunehehe Mar 26 '11 at 8:42

The underlying problem is that the mapping done by screen between the actual terminal (identified by the TERM environment variable outside screen) and the emulation within screen is incomplete.

If you happen to test it (using vttest or tack), you may notice deficiencies for

  • colors
  • special keys

Attempting to fix these problems by setting term in .screenrc has the drawback that it works only for a given actual-terminal, and is not portable to other terminal implementations. The documentation notes

The use of the term command is discouraged for non-default purpose.

There is another solution (with a different drawback), using this feature from screen documentation:

When screen tries to figure out a terminal name for itself, it first looks for an entry named screen.term, where term is the contents of your $TERM variable. If no such entry exists, screen tries screen (or screen-w, if the terminal is wide (132 cols or more)). If even this entry cannot be found, vt100 is used as a substitute.

ncurses provides several useful alternate terminal descriptions for this case, e.g., screen.xterm-new, to repair problems in screen's mapping. In practice, I use TERM=xterm-new, and when running screen, get a usable mapping of function keys.

Referring back to screen's term setting, in testing you may notice that there are still problems with the mapping, which are addressed in these alternatives. If it were possible to get an accurate terminal description using term, these alternatives would be simple aliases to screen. They are not.

ncurses does not provide screen.xterm (sic) because:

  • TERM=xterm is misused widely for terminal emulators which differ from xterm; adding this mapping would only aggravate that situation (see for example Why not just use TERM set to "xterm"? in the ncurses FAQ)
  • the alternative name screen.xterm is less likely to be installed on remote systems (see change comment from June 2015 in the terminal database).

On the whole, however, using the alternate names is an improvement over using term in your .screenrc: it solves more problems than it creates. The reverse is true of the term setting.

share|improve this answer

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.