[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Superfluous newlines after ^D when using external event loop
From: |
Juerd Waalboer |
Subject: |
Superfluous newlines after ^D when using external event loop |
Date: |
Sun, 11 Feb 2024 05:02:12 +0100 |
Hi,
Since some recent-ish version of readline, the program revbank[1] of which I'm
the main author, sometimes got into a state where there would be an extra
newline after the input line. This would continue until the process was
terminated.
Initially it wasn't clear how to reproduce this, but it turned out to start
with ^D, the eof character, at an empty input line. The program is not supposed
to be exitable by users (kiosk mode), so ^D does not exit the program and a new
prompt is presented instead.
With strace, I found that before the first use of ^D, there was a call of write(4,
"\33[?2004l\r", 9) after pressing enter at the prompt, which after the first use of ^D
turned into write(4, "\33[?2004l\r\n", 10).
Grepping the source for 2004l came up with BRACK_PASTE_FINI, and specifically, the
addition of a "\n" if bracketed paste is enabled and rl_eof_found is true, in
rl_deprep_terminal().
It does seem the \n is useful, but only once. However, because rl_eof_found
remains true, the \n is then printed after each input. With
readline_internal(), rl_eof_found is reset to false, but if you write your own
event loop, you'd have to do that yourself.
The Perl wrapper Term::ReadLine::Gnu does not expose rl_eof_found, so I
fixed[2] it by using readline's internal loop instead; which is arguably the
better solution anyway - I probably didn't know about event_hook to add custom
stuff when I originally wrote that code.
The version number and release status of Readline (e.g., 4.2-release)
Tested with 8.2-1.3 in Debian. I don't know the first version in which the
behavior appeared.
The machine and OS that it is running on
Debian GNU/Linux
A list of the compilation flags or the contents of `config.h', if appropriate
No idea, but I don't think that's going to be relevant. Callbacks were enabled.
a description of the bug
When using an external event loop, rl_eof_found is not reset to false after
ignoring the eof character, causing all subsequent depreps to include an
additional \n (and thus an empty line) if bracketed paste is enabled.
Programs that exit on ^D will not encounter the bug.
Programs that use readline's internal character loop will not encounter the bug.
a recipe for recreating the bug reliably
RevBank before this commit[2]. A much smaller test case could be made, but I
lack the spoons to do so.
a fix for the bug if you have one!
rl_eof_found is reassigned in rl_callback_read_char() iff eof > 0. I think it
should perhaps be done unconditionally, so that it can return to false again. I
have not tested if that helps.
[1] https://github.com/revspace/revbank
[2]
https://github.com/revspace/revbank/commit/2b0f8febf0905ca9351757fe1b9f3c9a6f21a13d
--
Met vriendelijke groet, // Kind regards, // Korajn salutojn,
Juerd Waalboer <juerd@tnx.nl>
TNX
- Superfluous newlines after ^D when using external event loop,
Juerd Waalboer <=