[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Superfluous newlines after ^D when using external event loop
From: |
Juerd Waalboer |
Subject: |
Re: Superfluous newlines after ^D when using external event loop |
Date: |
Mon, 12 Feb 2024 16:18:30 +0100 |
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