22

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?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
Alois Mahdal
  • 4,330
  • 11
  • 40
  • 62
  • 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 06 '14 at 19:40

2 Answers2

25

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.

Community
  • 1
terdon
  • 234,489
  • 66
  • 447
  • 667
  • 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). – Alois Mahdal Jan 06 '14 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. – Alois Mahdal Jan 06 '14 at 21:04
12

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.

Notes:

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.

Community
  • 1
Alois Mahdal
  • 4,330
  • 11
  • 40
  • 62
  • 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 07 '14 at 00:56
  • See updated answer for how to specifically enable Alt+arrows. – terdon Jan 07 '14 at 02: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 07 '14 at 02: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 `$include`d by default). – Alois Mahdal Jan 07 '14 at 09: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). – Alois Mahdal Jan 07 '14 at 09:54
  • Gosh, s/initrc/inputrc/g :D – Alois Mahdal Jan 07 '14 at 10:00