Red Hat Bugzilla – Bug 24117
/etc/inputrc breaks vi mode in bash if set from .bashrc
Last modified: 2014-03-16 22:18:09 EDT
There is an unfortunate conflict between the bindings in /etc/inputrc
(setup-2.3.6-1) and bash in vi-mode (bash-2.04-15). If I have "set -o vi"
in my .bashrc, I can't do command line editing as I expect. This seems to
be because of /etc/inputrc; if I start bash with INPUTRC=/dev/null it works
fine. It ALSO works fine if I start bash without the set command in
.bashrc, but do it by hand later.
I assume it is about how ESC is being bound. When the "set -o vi" command
is done, it is set to vi-movement-mode, but when /etc/inputrc is sourced
sequences beginning with ESC is bound to other things. It appears the one
happening last "wins", and the commands in .bashrc is presumably executed
before the ones in /etc/inputrc. This is obviously not the complete story,
though; if I have "set -o vi" in .bashrc, type "set -o emacs" and then "set
-o vi" again, it don't start working. I haven't dug into the details.
I would suggest protecting the section of key sequence bindings in
/etc/inputrc with "$if mode=emacs" and "$endif". The bindings don't make
much sense in vi mode in any case.
In principle, it seems each group of bindings should ALSO be enclosed by
"$if term=xxx"-"$endif". I haven't been bitten by this, but it could
happen, and would hardly hurt, would it?
This seems to resemble bug 7710. But that one is marked as fixed almost
exactly a year ago, and I see this with packages from Florence beta 2.
This can be fixed by using ~/.inputrc (/etc/inputrc won't be sourced
in that case.)
I agree it CAN be solved in that way but:
1. For a naove user, maybe migrating from ksh in a non-Linux environment, it
won't be very obvious.
2. Is anything gained from the extra work required from users to maintain their
own .inputrc files, rather than having an "$if mode"-conditional in the
default? The key bindings in there is not usable in vi mode in any case.
I don't want to nag, but maybe you could consider this once more before we close
Oops. I misunderstood the default settings; I assumed it defaulted
to *no* mode, as opposed to emacs mode.
Fixed in 2.3.8-1.