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
[EMAIL PROTECTED]
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
> [EMAIL PROTECTED]
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
