Red Hat Bugzilla – Bug 143040
/etc/inputrc keysequence bad for CTRL-left / CTRL-right in xterm
Last modified: 2014-03-16 22:51:13 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: /etc/inputrc attempts to set up CTRL-left and CRTL-right (cursor arrow keys) to backward-word and forward-word respectively. However I find that they do not work correctly in xterm. In gnome-terminal the key combination works, but in xterm it results in "5D" being written at current curson position. Note: as a work-around the emacs Alt-f and Alt-b combinations do work in both cases. Version-Release number of selected component (if applicable): 2.05b-38 How reproducible: Always Steps to Reproduce: 1. start xterm with bash as shell 2. type command 3. CTRL-left Actual Results: prints "5D" Expected Results: cursor should have moved backward by a word Additional info: This can be fixed for xterm by modifying /etc/inputrc as follows Change these lines "\e[5C": forward-word "\e[5D": backward-word to "\e[1;5C": forward-word "\e[1;5D": backward-word
Just discovered that the above fix breaks bash in gnome-terminal. I guess the real fix lies somewhere in standardising the behaviour of xterm and gnome-terminal, but I'm not an expert and don't know which one is misbehaving. Is it possible to have conditional inputrc sections? Eg. gnome-terminal identifies itself by setting COLORTERM=gnome-terminal, while xterm does not.
This should work in FC3. *** This bug has been marked as a duplicate of 80860 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.