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

[Chet Ramey]

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    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature