This patch amends bash.1 to explain the sequence of places the
inputrc is found (INPUTRC, ~/.inputrc, /etc/inputrc) in the same
way as in readline.3 and bash.info.
The existing text had me puzzled for a bit, as it seemed to say
that /etc/inputrc wasn't part of Bash's own behavior, even though
I knew I'd seen it take effect when I didn't have a ~/.inputrc.
I spent a few minutes searching to see where in my dotfiles or in
/etc/ the convention of /etc/inputrc might have come from, before
finding it in a grep of the Bash source tree. :-) Hopefully this
patch can prevent the same confusion for others.
diff --git doc/bash.1 doc/bash.1
index 151c14cb5..7ba22b614 100644
@@ -5492,6 +5492,8 @@ The name of this file is taken from the value of the
variable. If that variable is unset, the default is
.IR ~/.inputrc .
+If that file does not exist or cannot be read, the ultimate default is
+.IR /etc/inputrc .
When a program which uses the readline library starts up, the
initialization file is read, and the key bindings and variables
On 5/3/20 11:01 PM, Greg Price wrote:
> This patch amends bash.1 to explain the sequence of places the
> inputrc is found (INPUTRC, ~/.inputrc, /etc/inputrc) in the same
> way as in readline.3 and bash.info.