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

[Juerd Waalboer]

Chet Ramey skribis 2024-02-12  9:48 (-0500):
> 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?

If the introduction of the newline with bracketed paste is indeed intended as a 
breaking change to existing programs that now need to do one thing extra, then 
that seems fair.

However, since no such responsibility or breaking change was documented, I 
assumed it was intended that existing programs would continue to work as 
before, and that this variable being reset in one circumstance but not another, 
should be classified as a bug.

Personally I think adding additional responsibilities to the caller's side 
would warrant explicit documentation; the change that introduced this behaviour 
seems to have been a minor change. Besides that, I don't think it is 
necessarily the caller's responsibility, because it can more easily and more 
consistently be fixed in readline itself, which would also retroactively fix 
all affected existing programs. Why fix decentrally if a centralized solution 
is possible - isn't that the whole purpose of using libraries in the first 
place?

> Its purpose, after all, is to communicate state to the
> calling application.

Which it would still do if it is updated to indicate that due to continued 
interactive use of readline, there is not actually an eof condition anymore.

But now, from the first use of ^D in a custom event loop, the flag becomes 
meaningless because it will always be true. It doesn't correctly serve its 
purpose in this situation.

Since there's if (eof > 0) { rl_eof_found = eof; ... } in rl_callback_read_char(), with 
the comment "/* Make sure application hooks can see *wether* we saw EOF */" 
(emphasis mine), it seems to me that it should be updated true to whether eof was seen, and 
thus not conditionally on eof being true (or here, positive) in the first place.

Either way, I have no horse in this race anymore. I do think it would make 
sense to classify this as a bug in readline, and fix it there, but I have 
changed my program and am aware of at least 3 workarounds.
--
Met vriendelijke groet, // Kind regards, // Korajn salutojn,

Juerd Waalboer  <juerd@tnx.nl>
TNX