Hi,
TL;DR: binding of reverse-search-history and forward-search-history to a
combination of more than one key leads to wrong behavior: the search string
gets reset.
Details:
To reproduce:
1. Add the following lines to inputrc:
# built-in binding
"\C-s": forward-search-history
# single-key custom binding
"\C-f": forward-search-history
# double-char custom binding: Meta-Control-R
"\e\C-r": forward-search-history
# multichar custom binding: Control-PageDown
"\e[6;5~": forward-search-history
2. Start bash
3. List the current bindings:
$ bind -p | fgrep forward-search-history
"\C-f": forward-search-history
"\C-s": forward-search-history
"\e\C-r": forward-search-history
"\e[6;5~": forward-search-history
# non-incremental-forward-search-history (not bound)
# non-incremental-forward-search-history-again (not bound)
4. Press Ctrl-R (built-in reverse-search-history) and start typing
something that exists in the history
(reverse-i-search)`ls': ls
5. Press Ctrl-R several times: some other command lines with substring
"ls" appear:
(reverse-i-search)`ls': ls -l
(reverse-i-search)`ls': ls qq
(reverse-i-search)`ls': ls -lt
6. Now let us see the difference between the behavior of the command
forward-search-history bound to different keys:
a. Ctrl-F and Ctrl-S (in case "stty -ixon" is done) work as expected.
b. Any key combination which consists of more than one character clears
the search string and the search stops.
* The same applies to attempts of binding reverse-search-history to more
than one key.
* No matter how exactly the binding is done: either by .inputrc or bash
"bind" command. The results are identical.
I was unable to find any mentions of this bug in Google and assumed that is
can be a new one.
Best regards,
Yury
_______________________________________________
Bug-readline mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-readline
