aboutsummaryrefslogtreecommitdiff
path: root/elfcpp/elfcpp_file.h
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2024-12-20 18:34:50 +0100
committerTom de Vries <tdevries@suse.de>2024-12-20 18:34:50 +0100
commit602f66f5aba3b3871cef08306f9c3c2962992784 (patch)
tree93f71d719d80f2aed3260d3f40f67ba353029933 /elfcpp/elfcpp_file.h
parent66834f8da920eb2f2c348259046667decdcfb822 (diff)
downloadbinutils-602f66f5aba3b3871cef08306f9c3c2962992784.zip
binutils-602f66f5aba3b3871cef08306f9c3c2962992784.tar.gz
binutils-602f66f5aba3b3871cef08306f9c3c2962992784.tar.bz2
[gdb/cli] Don't prefill for operate-and-get-next of last command
Consider operate-and-get-next [1] in bash: ... $ <echo 1>echo 1<enter> 1 $ <echo 2>echo 2<enter> 2 $ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o> 1 $ echo 2<Ctrl-o> 2 $ echo 1 ... So, typing Ctrl-o: - executes the recalled command, and - prefills the next one (which then can be executed again with Ctrl-o). We have the same functionality in gdb, but when recalling the last command from history with bash we have no prefill: ... $ <echo 1>echo 1<enter> 1 $ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o> 1 $ ... but with gdb do we have a prefill: ... (gdb) echo 1\n 1 (gdb) <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1\n<Ctrl-o> 1 (gdb) echo 1\n ... Following the principle of least surprise [2], I think gdb should do what bash does. Fix this by: - signalling this case in gdb_rl_operate_and_get_next using "operate_saved_history = -1", and - handling operate_saved_history == -1 in gdb_rl_operate_and_get_next_completion. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR cli/32485 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485 [1] https://www.man7.org/linux/man-pages/man3/readline.3.html [2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
Diffstat (limited to 'elfcpp/elfcpp_file.h')
0 files changed, 0 insertions, 0 deletions