Re: Superfluous newlines after ^D when using external event loop

[Chet Ramey]

On 2/10/24 11:02 PM, Juerd Waalboer wrote:

> 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.

That seems reasonable. If your application wants to ignore EOF and go
back into rl_callback_read_char, shouldn't it be responsible for resetting
rl_eof_found? Its purpose, after all, is to communicate state to the
calling application.

The variable changed from private (_rl_eof_found) to public (rl_eof_found)
in bash-5.2/readline-8.2 just so applications could check it -- in
particular in the deprep-term hook or the line handler.

https://lists.gnu.org/archive/html/bug-readline/2022-01/msg00002.html
explains why the \n is there.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature