Re: Readline-8.2-beta available

[Andrew Burgess]

Andrew Burgess <aburgess@redhat.com> writes:

> Andrew Burgess <aburgess@redhat.com> writes:
>
>> Chet Ramey <chet.ramey@case.edu> writes:
>>
>>> The first beta release of the GNU Readline library, version 8.2,
>>> is now available with the URLs
>>>
>>> ftp://ftp.cwru.edu/pub/bash/readline-8.2-beta.tar.gz
>>> https://ftp.gnu.org/pub/gnu/readline/readline-8.2-beta.tar.gz
>>>
>>> and from the readline-8.2-testing branch in the readline git repository
>>> (http://git.savannah.gnu.org/cgit/readline.git/log/?h=readline-8.2-testing).
>>>
>>> You can use
>>>
>>> git clone --branch readline-8.2-testing 
>>> git://git.savannah.gnu.org/readline.git
>>>
>>> to clone the testing branch.
>>>
>>> The CWRU FTP site works best if your client supports Extended Passive
>>> (EPSV) mode.
>>>
>>> This distribution is essentially a standalone version of the
>>> readline library that appears in bash-5.2-beta together with
>>> an `autoconf' framework.  The documentation has been updated and
>>> is current.  Postscript, DVI, and Info versions of the Readline
>>> and History manuals are included.  A list of changes in this
>>> release is appended to this announcement.
>>>
>>> This release accompanies the simultaneous release of bash-5.2-beta.
>>> There are more improvements in the programming interface and new
>>> user-visible variables and bindable commands.
>>>
>>> The most visible new feature is the addition of a new option which allows
>>> users to turn off the active region support without disabling bracketed
>>> paste. The option has the same default value as bracketed-paste, and
>>> enabling bracketed paste enables the active region. When the default
>>> value of of bracketed paste is enabled, unsetting this option in an
>>> inputrc file should suffice to disable active region support.
>>>
>>> There are two new bindable readline variables, active-region-start-color
>>> and active-region-end-color. The first sets the color used to display the
>>> active region; the second turns it off. If set, these are used in place of
>>> the escape sequences that enable and disable terminal standout mode.
>>>
>>> There are bug fixes for redisplaying the prompt when aborting incremental
>>> searches or switching to and from a digit-argument prompt. There is a fix
>>> for a redisplay problem that caused the prompt to be wrapped incorrectly
>>> if the screen changed dimensions during a call to readline() and the prompt
>>> became longer than the screen width. There are fixes for a couple of
>>> problems that could cause rl_end to be set incorrectly.
>>>
>>> Full details of the changes and bug fixes are below.
>>>
>>> GNU Readline is a library which provides programs with an input
>>> facility including command-line editing and history.  Editing
>>> commands similar to both emacs and vi are included.  The GNU
>>> History library, which provides facilities for managing a list of
>>> previously-typed command lines and an interactive command line
>>> recall facility similar to that provided by csh, is also present.
>>> The history library is built as part of the readline as well as
>>> separately.
>>>
>>> Since this is a testing release, please send readline bug reports to
>>> chet.ramey@case.edu.
>>
>> 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
>
> Apologies, I inadvertently hit send on this email prematurely.
>
> I was going to finish with:
>
>   ... I don't currently understand what's going wrong here, but thought
>   I should raise this issue for consideration.

Here's a strawman patch:

## START ##

diff --git a/callback.c b/callback.c
index 1a3235f..a7b0b0b 100644
--- a/callback.c
+++ b/callback.c
@@ -279,7 +279,7 @@ rl_callback_read_char (void)
        }
 
       /* Make sure application hooks can see whether we saw EOF. */
-      if (rl_eof_found = eof)
+      if (rl_eof_found = (rl_done && eof))
        RL_SETSTATE(RL_STATE_EOF);
 
       if (rl_done)

## END ##

My thinking is that the user only really cares about the eof state when
rl_done is true.  In any other case the line is not going to be sent
back to the user, so clearly, no matter what eof says, we're not really
in an eof state.

I am a little suspicious that some of the assignments to eof in
rl_callback_read_char might be ... misleading maybe, I'm not sure that
eof always represents a boolean, for example, we compare eof to -1, and
-2 in some cases.  In the problem I reported in this thread, eof ends up
as -3!  All these are interpreted as EOF, which I don't think is right.

Anyway, I'd be interested to hear your thoughts.

Thanks,
Andrew