PR cli/21690 reports the following: say we start gdb:
...
$ gdb -q
(gdb)
...
and press ^R for reverse-i-search:
...
(reverse-i-search)`':
...
Pressing the p key has the effect of showing both the pressed key and a
matching entry, which happens to be up:
...
(reverse-i-search)`p': up
...
Now we press ^C to cancel the search:
...
(reverse-i-search)`p': u❌️ Quit
(gdb)
...
and type "down".
We expected to get:
...
(gdb) down
...
but instead we get:
...
(failed reverse-i-search)`pdown':
...
So we're stuck in reverse-i-search, until we use the workaround of ^G.
The same problem happened with python [1], was reported upstream [2], and
fixed in cpython commit
d6990d221b0 ("Issue #24266: Cancel history search mode
with Ctrl+C in Readline 7") using rl_callback_sigcleanup.
Fix this likewise in quit using rl_callback_sigcleanup, a new callback
function in readline 7.0:
...
i. rl_callback_sigcleanup: a new application function that can clean up and
unset any state set by readline's callback mode. Intended to be used
after a signal.
...
giving us instead:
...
$ gdb
(gdb) u❌️ Quit
(gdb) down
...
Remove the corresponding kfail in gdb.tui/pr30056.exp.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21690
[1] https://bugs.python.org/issue24266
[2] https://lists.gnu.org/archive/html/bug-readline/2015-05/msg00014.html
throw_forced_quit ("SIGTERM");
}
+ /* Pressing ^C cancels i-search. Tell readline that a ^C happened. */
+ rl_callback_sigcleanup ();
+
#ifdef __MSDOS__
/* No steenking SIGINT will ever be coming our way when the
program is resumed. Don't lie. */
# Send ^C to clear the command line.
send_gdb "\003"
} else {
- # Sending ^C currently doesn't abort the i-search. PR cli/30498 is
- # open about this.
- kfail cli/30498 $test
+ # Sending ^C currently doesn't abort the i-search.
+ fail $test
# At this point we don't have a responsive prompt. Send ^G to abort
# the i-search.