Re: Readline-8.2-beta available

[Chet Ramey]

On 4/26/22 8:55 AM, Andrew Burgess wrote:

> I found an issue with the alternative callback API and EOF detection
> that was added after my earlier requests:
>
>    https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html
>
> It appears that in some cases the EOF flag will be set when I don't
> think that it should be.
>
> I've included a test program at the end of this email, the test is based
> on the alternative interface example from the manual.
>
> Build the test and run it, you'll see something like this:
>
>    rltest$
>
> type anything you like at the prompt (I use 'abc') and then press
> return, the application echos your input back.  You should see this:
>
>   rltest$ abc
>   input line: abc
>   rltest$
>
> Now if I use the up arrow key to select my previous input, and press
> return, the complete output is now this:
>
>    rltest$ abc
>    input line: abc
>    rltest$ abc
>    quit
>    input line: abc
>    rltest$
>
> Notice the extra 'quit' that appeared.  This was from cb_deprep_terminal
> (installed as rl_deprep_term_function) in the program below, the quit is
> printed when the EOF flag is set.
>
> The problem seems to originate from the handling of 'RL_ISSTATE
> (RL_STATE_MULTIKEY)' in rl_callback_read_char (callback.c), where eof is
> set as a result of calling _rl_dispatch_callback.  I don't currently
> understand what the return value of _rl_dispatch_callback actually
> represents

OK. The callback interface is designed to work with individual characters
when the application indicates to readline it has input available (this is
the rl_callback_read_char interface). There are a number of places where
readline needs to read multiple characters to do something -- it's not a
pure read-and-dispatch loop.

One of those cases is multiple-character key sequences (RL_STATE_MULTIKEY).
There has to be a way not only to indicate that readline is in the middle
of reading a key sequences and dispatching to different keymaps but to
keep state about what it's doing. You can have "a" bound to self-insert and
"abcd" bound to a macro that inserts `rm -rf /', and you have to treat them
differently, so you have to keep reading input until you get to something
that's unambiguous. You have to have a way to indicate the "a" is
`shadowed' and a way to keep track of where you are in the key sequence
you're trying to read (what happens if you read `abe'?).

The code uses return values < 0 to simulate recursing through a chain of
dispatch calls (but only the second and subsequent times!). The -3 return
value means that we haven't read enough input to determine an unambiguous
key sequence and should keep recursing. -2 means we didn't match anything
with what we read so far so we need to go back to a previous `shadowed'
subsequence (this happens when you have one key sequence "abc" and another
"abcd" both bound to readline commands and you read "abce"). -1 means that
we didn't find a key sequence bound to what we've read so far and we need
to go further back in the simulated recursion chain to find the part of the
current key sequence that is bound to a command.

This is what _rl_dispatch_subseq() and _rl_subseq_result() do. They are
supposed to be internal; the negative values shouldn't be returned to the
application.

Looking at the RL_STATE_MULTIKEY code in the callback dispatch function, I
have to see why it doesn't handle -3. It might be that that value should be
ignored, since it means we need to keep reading input, and we should only
set rl_eof_found if eof > 0.

--
``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/