After these two commits:
commit
4fb7bc4b147fd30b781ea2dad533956d0362295a
Date: Mon Mar 7 13:49:21 2022 +0000
readline: back-port changes needed to properly detect EOF
commit
91395d97d905c31ac38513e4aaedecb3b25e818f
Date: Tue Feb 15 17:28:03 2022 +0000
gdb: handle bracketed-paste-mode and EOF correctly
It was observed that, if a previous command is selected at the
readline prompt using the up arrow key, then when the command is
accepted (by pressing return) an unexpected 'quit' message will be
printed by GDB. Here's an example session:
(gdb) p 123
$1 = 123
(gdb) p 123
quit
$2 = 123
(gdb)
In this session the second 'p 123' was entered not by typing 'p 123',
but by pressing the up arrow key to select the previous command. It
is important that the up arrow key is used, typing Ctrl-p will not
trigger the bug.
The problem here appears to be readline's EOF detection when handling
multi-character input sequences. I have raised this issue on the
readline mailing list here:
https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00012.html
a solution has been proposed here:
https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00016.html
This patch includes a test for this issue as well as a back-port of
(the important bits of) readline commit:
commit
2ef9cec8c48ab1ae3a16b1874a49bd1f58eaaca1
Date: Wed May 4 11:18:04 2022 -0400
fix for setting RL_STATE_EOF in callback mode
That commit also includes some updates to the readline documentation
and tests that I have not included in this commit.
With this commit in place the unexpected 'quit' messages are resolved.
}
}
+ # Use the up arrow to select a previous command. Check that
+ # no unexpected output is added between the previously
+ # selected command, and the output of that command.
+ gdb_test "print 123" "\\\$\[0-9\]* = 123"
+ gdb_test_multiple "\033\[A" "use up arrow" {
+ -re -wrap "print 123\r\n\\\$\[0-9\]* = 123" {
+ pass $gdb_test_name
+ }
+ }
+
# Now repeat the first test with a history file that fills the entire
# history list.
}
/* Make sure application hooks can see whether we saw EOF. */
- if (rl_eof_found = eof)
- RL_SETSTATE(RL_STATE_EOF);
+ if (eof > 0)
+ {
+ rl_eof_found = eof;
+ RL_SETSTATE(RL_STATE_EOF);
+ }
if (rl_done)
{