[Bug-readline] Re: rlwrap: configure.ac and cross_compiling

[Cristian Ionescu-Idbohrn]

On Thu, 13 May 2010, Hans Lub wrote:

> Hello Cristian

Hello again Hans,

> There are quite a few reasons I read() the keystrokes myself and then
> use rl_stuff_char() to feed them to readline.
> (avoiding a quirk with CTRL-D on Solaris, much more readable logfiles,
> to name a few) None of those reasons are cast in stone, but on the other
> hand, according to the documentation, it should work (and it does - in
> 10 years rlwrap has been running on many outlandish unix systems, and
> this bug has never cropped up!)

Right.  I didn't mean to doubt or question your knowledge and/or
experience with using the readline lib over the years.  I'm just trying to
understand what's going on and get enough material to eventually send to
the readline upstream maintainer.

> So I still consider it a bug with readline on your platform.

That arch is 'crisv32', by the way.

> Even if the attached rltest4.c works correctly on your system (and I
> suspect it will)

Yes, it does work (sortof).  After the prompt:

        Enter a line:
                      ^^^
I typed 'foo' there, but nothing is echoed, and after hitting <Enter>,
this is what I see:

        Enter a line: You typed: 'foo'
        History list now:
        0: 'foo'*
        Enter a line:
                      ^
                      with the cursor waiting here for new input

> then still rl_stuff_char() is misbehaving on your system

Yes, it does.  I can confirm that.  It's not swallowing every other odd
(numbered) character echoing and (eventually) using only the even
(numbered) characters, as 'rlwrap' and the initial 'rltest1' shows.

> - or, improbably but possibly, it is returning an error (for which I
> never tested until now)

No, it doesn't return any error I can notice.  This is what I see:

        # ./rltest4
        Enter a line: You typed: 'foo'
        History list now:
        0: 'foo'*
        Enter a line: You typed: 'bar'
        History list now:
        0: 'foo'
        1: 'bar'*
        Enter a line: You typed: 'baz'
        History list now:
        0: 'foo'
        1: 'bar'
        2: 'baz'*
        Enter a line: #
                      ^^^
                      | |
                      | Cursor
                      Ctrl-D here to exit; no <NL> echoed;
                      system prompt '# ' shows up followed by
                      a blinking cursor

Running the same test program on a 'i686', shows different behaviour:

        $ ./rltest4
        Enter a line: foo
        You typed: 'foo'
        History list now:
        0: 'foo'*
        Enter a line: bar
        You typed: 'bar'
        History list now:
        0: 'foo'
        1: 'bar'*
        Enter a line: baz
        You typed: 'baz'
        History list now:
        0: 'foo'
        1: 'bar'
        2: 'baz'*
        Enter a line: $

> So, at the very least,  this exposes my failure to test rl_stuff_char()'s
> return value. A look into readlines source code reveals that rl_stuff_char
> only returns an error if the input queue already contains 512 bytes, which
> sounds impossible.

Right.  Nothing like that in this example.

> Anyway, in rltest1.c I now test the return value - I'm curious to know how
> it will behave on your machine.

I renamed your second rltest1.c to rltest1.1.c.

On the 'crisv32' (result after typing a single 'f'):

        # ./rltest1.1
        Enter a line:
        Disappointingly, I couldn't even stuff a single 'f' into
        readline's 512-byte long input queue, giving up :-(

On a 'i686':

        $ ./rltest1.1
        Enter a line: ffoooo
        You typed: 'ffoooo'
        History list now:
        0: 'ffoooo'*
        Enter a line:
        You typed: ''
        History list now:
        0: 'ffoooo'
        1: ''*
        Enter a line:

Please note that what I typed in the example above was actually 'foo' and
not 'ffoooo'.

> So, to wrap up, could you please test both the attached newer rltest1.c

(renamed, as mentioned, to rltest1.1.c)

> and rltest4.c

See the results above.

> Tomorrow I'll be on a long train journey, and only have a very small
> computer, so I'll probably read a book, instead of programming.

Enjoy your trip and the book, and hope to here more from you soon.
Thanks so much again for looking into this.

I've Cc:ed this conversation to Chet too.
I also attached your rltests for reference.


> 2010/5/13 Cristian Ionescu-Idbohrn <address@hidden>
>
> > On Thu, 13 May 2010, Hans Lub wrote:
> >
> > > Hello Cristian
> >
> > Hans,
> >
> > > I compiled and (statically) linked rlwrap with readline 5.1 and
> > > rlwrapped dash with it, but no bug here, alas.
> > >
> > > I'm really stuck here. What happens is that rlwrap accepts your
> > > keystroke (say "l"), stuffs it into readline's read queue and then
> > > calls readline's rl_callback_read_char() to read the next character.
> > > Normally, readline will find the stuffed character and happily do
> > > its thing with it, but in your case readline will still be hungry
> > > and therefore read() another keystroke from stdin. I suspect that
> > > typing "qlqs" (or, less likely, "lqls") will give the same result as
> > > "llss"
> >
> > True.  "qlqsq<NL>" gives the same result as "llss<NL><NL>".
> > Looks like readline eates every odd (number) character and keeps the
> > even ones.
> >
> > > Now, from here, it looks like a readline bug, but I couldn't find
> > > any mention of "rl_callback_read_char" in readline's CHANGELOG or
> > > NEWS
> > >
> > > The most sensible thing to do now:
> > >
> > >    - compile and run the attached rltest1.c (instructions included).
> > >      It will probably misbehave in the same way.
> >
> > That I did.  Picked up:
> >
> >        http://ftp.gnu.org/pub/gnu/readline/readline-5.2.tar.gz
> >
> > and applied patches:
> >
> >        http://ftp.gnu.org/pub/gnu/readline/readline-5.2-patches/*
> >
> > And yes, it does still misbehave :(
> >
> > >    - if so, do the same with the newest readline version. If this
> > >      works well, you're done
> >
> > Did that too.  Same misbehaviour :(
> >
> > >    - but if not, file a bug report with the readline maintainer
> > >      (Chet Ramey)
> >
> > Before doing that...  I dug up some more.  Built the examples that
> > follow with the readline package.  Among them, 'rltest'.  That works
> > as expected on my embeded system.  Yes, it does things differently
> > from your 'rltest1'.  Reads one line at a time (and echoes every
> > character as expected).
> >
> > 'rltest1' reads one char at a time.  I also noted it uses a
> > traditional 'read', not an 'rl_*' function (there's no such thing
> > available to do exactly that).
> >
> > Stumbled over two other examples (which are not built as part of the
> > examples target, and FTBFS), that might (or might not) pinpoint on the
> > complexity.
> >
> >        readline/examples/excallback.c
> >        readline/examples/rlptytest.c
> >
> > Hope I'm not stepping on your toes suggesting there might be something
> > less than optimal in rlwrap, which may (or may not) have undesired side
> > effects :)
> >
> >
> > Thank you so much for looking into this.


Cheers,

-- 
Cristian

rltest1.c
Description: Text Data

rltest1.1.c
Description: Text Data

rltest4.c
Description: Text Data