On a Debian Wheezy machine at previous job, I got used to Alt+Left and Alt+Right to skip between words on active command-line (in bash).

However, since at home I have upgraded to Jessie (Debian 8.0, testing branch) this does not work anymore: instead of skipping to previous word, Alt-Left prints something like D or [D. OTOH, if I open ssh and connect to my headless Debian Wheezy, it does work perfectly.

Furthermore, I just installed Fedora 20 in my new job and here the behavior is the same. This applies to bash, csh and ksh (started under env -i), as well as rxvt-unicode and xfce4-terminal, so it must be something outside these level.

Where else in the stack should I look to find the difference?

  • 4
    I would suggest trying alt-b and alt-f (as well as the rest of the readline keys), as they are more universal, and quite a number of command line programs honor readline bindings.
    – demure
    Jan 6, 2014 at 19:40

2 Answers 2


You probably had a local ~/.inputrc or global /etc/inputrc file defined that was lost on the upgrade. An easy fix is to create an ~/.inputrc file with the following lines:

## enable Alt-arrows 
"\e[1;3D": backward-word ### Alt left
"\e[1;3C": forward-word ### Alt right

Those will work with xterm and terminator and gnome-terminal but might need to be tweaked for other terminals. Unfortunately, each terminal emulator can use a different syntax. For some more details, see my answer here.

  • I really meant Alt, and it still works on the remote machine. Ctrl+Left/Right is already taken in Rxvt to move tab left and right (Shift+Left/Right switching the tabs and Shift+Down opening new one). Jan 6, 2014 at 21:01
  • 1
    By the way while Ctrl+Left/Right is common in GUI editors, terminals are completely different world where I haven't seen that combination yet. Jan 6, 2014 at 21:04

terdon set me in the right direction: inputrc file.

The culprit is that quite non-intuitively, readline6 actually uses ~/.inputrc instead of /etc/inputrc, which readline(3) does not emphasize nor rebute:

The name of this file is taken from the value of the INPUTRC environment variable. If that variable is unset, the default is ~/.inputrc. If that file does not exist or cannot be read, the ultimate default is /etc/inputrc.

So while in on both Debian machines /etc/inputrc is identical to that provided by libreadline6 package (the version is the same as well), on the newer machine ~/.inputrc exists with single line: set bell-style none. When this file is deleted, all works fine (see notes below).

I can't check Fedora until tomorrow but I guess it's the same problem. Update: On Fedora, ~/.inputrc did not exist, here the /etc/inputrc is simply different so it may not define this. As a hotfix I simply saved Debian's inputrc as my ~/.inputrc.


The mystery how it got changed during 7>8 upgrade remains unresolved, but partly can be accounted to my bad memory and some unintentional dotfiles' juggling. (BTW it was was not APT upgrade but rather reinstall and manual dotfile moving so maybe the ~.inputrc got in the way somehow.)

Also, When I say OK, I mean that it works with Ctrl everywhere except Rxvt (OK, I only checked xfce4-terminal but we know Rxvt is the usual rebel), where this is remapped to Alt, apparently because Ctrl is taken by Rxvt-specific functionality--move active tab in list.

As manpage mentions, with bash you can use built-in bind command to investigate what you currently have.

  • Nice catch, +1. Actually, it's more intuitive than you think. The default behavior is for user-specific dotfiles to have precedence over the system-wide defaults . Otherwise, users would not be able to change their setting.
    – terdon
    Jan 7, 2014 at 0:56
  • See updated answer for how to specifically enable Alt+arrows.
    – terdon
    Jan 7, 2014 at 2:18
  • 4
    This is normal, you need $include /etc/inputrc at the top of ~/.inputrc if you want to read that as well.
    – Chris Down
    Jan 7, 2014 at 2:20
  • @terdon it perfectly makes sense to prefer user settings before system-wide, but what I'd see as more intuitive would be that ~/.initrc would be "merged" into /etc/initrc (i.e. /etc/initrc would be $included by default). Jan 7, 2014 at 9:53
  • 1
    See: 1. hard-coded options, 2. /etc/initrc, 3. ~/.initrc --vs-- 1. hard-coded options 2. /etc/initrc OR ~/.initrc. The first way is much more flexible since it can easily be extended to lower level (e.g. per project, well I admit this example does not make so much sense with readline but you get the point). Jan 7, 2014 at 9:54

You must log in to answer this question.

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