Re: readline5 bug report

[S.Coffin]

Chet: A month ago I sent you this mail reporting a problem with readline
5.0.  I did not archive your reply, but I recall you said it would be
fixed "in the next release of readline."  Now I have tested readline 
5.1, and I find that this behavior is unchanged.  Is there anything I
can do to help solve this problem or determine what is happening,
perhaps test some proposed bug-fix??  Please let me know if I can help
in any way....

                             =S.Coffin
                             scoffin@jeffnet.org


On Sun, 2005-11-13 at 09:47 -0800, S.Coffin wrote:
> Here is an apparent bug in readline 5.0 as exposed on Fedora Core 4.
> bash and the readline library both show the bug; readline 4 (also
> shipped with FC4) does NOT show the incorrect behavior.  I built the
> 5.0 from source from your web site, including 5 patches, and it also
> shows the bug.
> 
> What I'm trying to do is set up the backspace key above the return
> to act like CTRL-h and the keypad left arrow key.  Used these lines
> in /etc/inputrc (and tried a lot of other variations too :-) to do it:
> 
> set editing-mode vi
> # convert the backspace key
> $if mode=vi
> set keymap vi
> "\x7f":backward-char
> $endif
> 
> Now when I try to edit a line (in vi mode), expect the backspace
> key to do backward-char.  This works the FIRST time you start a
> program, but subsequent calls to readline the backspace key seems
> to do "delete-backward-char", which is the default setting before
> remapping as above.  So the meaning of the backspace key changes
> depending on how many times in that program you have called
> readline().  Its like some initialized stuff gets lost between the
> first and subsequent entries to readline.  I am not fluent in emacs
> and did not try the emacs editing mode, sorry.
> 
> The following simple program exposes the bug when
> linked with readline5, but readline4 behaves as expected.  And
> bash also shows the problem.
> 
> /*********************************************************/
> /* rl.c
>  * S.Coffin  11/05
>  * readline 5.0 bug
>  *
>  * to show bug:  enter some text at XYZ prompt, then hit ESC to enter
>  * editing mode, then use backspace key to back up.  Should act the
>  * same as left-arrow and CTRL-h.  Works first time in, then on second
>  * and later calls to readline(), behavior seems to change from
>  * "backward-char" to "backward-delete-char"
>  *
>  * compile as:
>  *  cc rl.c -o rl -lreadline -lcurses
>  *  cc rl.c /root/readline/readline-5.0/shlib/libreadline.so.5.0 -o rl
> -lcurses
>  *
>  * but this works fine:
>  *  cc rl.c /usr/lib/libreadline.so.4.3 -o rl -lcurses
>  */
> 
> #include <stdio.h>
> #include <readline/readline.h>
> #include <readline/history.h>
> 
> main() {
> 
>     char *prompt="XYZ> ";
>     char *ret;
> 
>     ret=readline(prompt);            /* correct */
>     printf( ">>>%s<<<\n", ret );
>     ret=readline(prompt);            /* incorrect */
>     printf( ">>>%s<<<\n", ret );
>     ret=readline(prompt);            /* incorrect */
>     printf( ">>>%s<<<\n", ret );
> }
> /*********************************************************/
> 
> Thanks for your work, readline() is a cool tool.  Ever since the
> introduction of line-editing (in ksh wasn't it?), I've wondered
> why the readline() functions were not included at the TTY driver
level,
> so ALL text input would benefit.  Of course, this got a lot less
urgent
> with X Windows and GUI input methods....
> 
>                                    =S.Coffin
>                                    scoffin@jeffnet.org