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

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.