On 2/12/24 10:18 AM, Juerd Waalboer wrote:
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.
It was not; see the link below. The issue was that adding the \r to work around a problem with the Linux terminal driver introduced a slight incompatibility with previous versions of readline (overwriting partial output), and adding the newline to the end of the bracketed paste string restored the previous behavior. It was not a `breaking change', but rather a fix to restore some measure of backwards compatibility. It wasn't exposed to applications, which didn't need to do anything to obtain readline's previous behavior upon reading an EOF from the terminal.
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.
You have your chronology wrong. Bracketed paste came first, then making bracketed paste the default, then adding the \r to the end of the bracketed paste end string to work around the Linux kernel issue, then adding the newline to avoid overwriting partial output, which fixed a change from the previous behavior (from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903936). This was all done by 2018. The addition of rl_eof_found came almost four years later, to allow applications to do something other than the default behavior if they wanted.
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.
Exposing rl_eof_found didn't add any `additional responsibilities'. It exposed behavior that had been in place for years so the application could do something different if it chose.
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.
It depends on the circumtances. Only the caller can know whether or not it wants to ignore eof, and the caller can (now) manage that state. What backwards-compatible change to readline would you propose here? If you want readline to reset rl_eof_found in callback mode, where should it do that? What would make the most sense for applications that want to exit and don't want any partial output overwritten and those that want to ignore EOF?
Why fix decentrally if a centralized solution is possible - isn't that the whole purpose of using libraries in the first place?
How long will the application have to wait for the vendors to upgrade to a new readline release? This isn't a library issue -- it's a vendor/distro timeliness issue.
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.
OK, let's look at that. Where should readline perform this update? Under what conditions? What does your application do after getting a NULL line with rl_eof_found set to true in its line handler function?
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.
Maybe, but that's not how it's documented:
"Readline will set this variable when it has read an EOF character (e.g., the
stty @samp{EOF} character) on an empty line or encountered a read error and
is about to return a NULL line to the caller."
So what should readline do here, having informed the application that it
read an EOF? Where should it reset it? Would it be enough to reset it on
the next call to rl_callback_read_char, or does your application reinit
the callback mode state in this case?
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
