Red Hat Bugzilla – Bug 2738
inputrc not processed when bash is run
Last modified: 2008-05-01 11:37:50 EDT
~/.inputrc is not processed when bash is spawed via login,
new xterm, or exec'ing. so, you don't get to do ful things
set horizontal-scroll-mode On
set bell-style none
save my sanity, make this work.
*** Bug 2736 has been marked as a duplicate of this bug. ***
After upgrading from 5.2 to 6.0 I encountered this very
annoying problem. At console, Alt-b is backward word. In
an Xterm, it inserts itself. Creating a .inputrc containing
set convert-meta On
does not cause subsequent xterms to behave properly. nxterm
exhibits the same problem. ESC-b behaves properly in all
frop:11 $ echo $SHELL
frop:12 $ echo $BASH_VERSION
frop:13 $ rpm -q bash
frop:16 $ rpm -q -f /usr/X11R6/bin/xterm
*** Bug 2404 has been marked as a duplicate of this bug. ***
I just installed RH6.0, upgrading from a 5.2 system, and
I am finding that I cannot use the meta key to perform
Emacs-style editing operations from within bash or ncftp,
both of which use termcap. This worked fine in the latest
XFree86 package update released for 5.2, so I assume that
something has changed in termcap for 6.0.
Oddly enough, I can use the meta key as before when running
either rxvt or the GNOME terminal program, which suggests
the termcap entry for xterm having changed. However, tcsh
gets the meta key stuff right in an xterm window, and it
uses termcap directly, without going through readline.
Backing out the RH6.0 readline RPM and installing the 5.2
RPM makes no difference, so I doubt readline is the problem.
I use the meta keys all the time in both bash and ncftp, so
it's very confusing to have them misbehave.
*** Bug 2852 has been marked as a duplicate of this bug. ***
After doing "set -o vi", vi editing commands don't work
with bash anymore.
xterm does not format its columns properly using ls anymore -- they
don't line up like they should. I don't know if this is the same
problem or not, but I suspect that it is all related to the terminal
I don't know if this helps, but if I use xterm to rlogin into a RedHat
5.2 system from my 6.0 system, I can use alt/meta fine. I am not
familiar with the low-level workings of terminals, but the issue
doesn't seem to be with xterm per se, as an rlogin shell on another
machine has no problems in a RedHat 6.0 xterm. Also, I downloaded and
compiled xterm from XFree86 and had the same problem.
Hope this helps. Please fix this - it's driving me crazy!
One more thing ... I noticed that a fresh xterm does not have the
column-formatting problem *until* you try to use meta-backspace to
delete a word.
firstname.lastname@example.org tells me that this is caused by 6.0 adding
to /etc/profile, which activates the bogus config in /etc/inputrc
which has been there since 5.2 .
To restore proper function, remove the offending "set convert-meta"
*** Bug 2921 has been marked as a duplicate of this bug. ***
when I put "set -o vi" into .bashrc, ESC-k and ARROW-UP
stops working in the shell.
when I type it in manually instead, things work fine.
Could it have something to do with readline initialization ?
(I have no idea).
*** Bug 3116 has been marked as a duplicate of this bug. ***
After upgrading to redhat-6.0, the user's .inputrc files
Investigatigation revealed that INPUTRC is set in
/etc/profile, pointing to /etc/inputrc.
Worse, it assumes everybody want's editing-mode-emacs.
Even "Fixing it" by submitting "set -o vi" does not work,
because the key bindings in /etc/inputrc break
Most people know vi, not emacs. So it is a mystery to me why
you want to force emacs mode in bash, and even prevent the
bash builtin 'set -o vi' to work.
*** Bug 3376 has been marked as a duplicate of this bug. ***
When you put "set -o vi" in a .bash_profile in Red Hat 6.0,
vi mode doesn't work at all. When you type it in manually,
it works fine. This seems like a bug in readline, not a
choice of features as Cristian Grafton has suggested. When
one adds "set -o vi" to a .bashrc, then vi edit mode never
works correctly afterwards. When you type it in manually,
you get great results. Once bash processes the "set -o vi"
in a .bashrc, no amount changing edit modes manually will
make vi edit mode work correctly [emacs edit mode seems
It makes the system MUCH more unfriendly to vi users than
the old version was to emacs users. Yeah, home and end
work, but now nothing else does - at least not for vi users.
The workaround is given by David A. DeGraaf on the
I found that the new line in /etc/profile is culpable:
When I commented this out bash worked again as it should. I
have no idea why this line is there or what function is lost
by removing it. It's just one of those little mysteries...
*** This bug has been marked as a duplicate of 2397 ***