Bug 24117 - /etc/inputrc breaks vi mode in bash if set from .bashrc
Summary: /etc/inputrc breaks vi mode in bash if set from .bashrc
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: setup
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-16 16:12 UTC by Göran Uddeborg
Modified: 2014-03-17 02:18 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-01-30 22:05:30 UTC

Attachments (Terms of Use)

Description Göran Uddeborg 2001-01-16 16:12:43 UTC
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.

Comment 1 Bill Nottingham 2001-01-29 18:30:38 UTC
This can be fixed by using ~/.inputrc (/etc/inputrc won't be sourced
in that case.)

Comment 2 Göran Uddeborg 2001-01-30 11:38:14 UTC
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
this bug?

Comment 3 Bill Nottingham 2001-01-30 22:05:26 UTC
Oops. I misunderstood the default settings; I assumed it defaulted
to *no* mode, as opposed to emacs mode. 

Fixed in 2.3.8-1.

Note You need to log in before you can comment on or make changes to this bug.