Superfluous newlines after ^D when using external event loop

[Juerd Waalboer]

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