pcp
[Top] [All Lists]

Re: [pcp] readline support for dbpmda

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] readline support for dbpmda
From: Andrew Wansink <ajwans@xxxxxxxxxxx>
Date: Tue, 19 Jan 2010 11:07:22 +1100
Cc: kenj@xxxxxxxxxxxxxxxx
In-reply-to: <1263845063.15216.24.camel@xxxxxxxxxxxxxxxx>
References: <20100118073306.GD28197@dull> <20100118141033.GA18251@dull> <1263845063.15216.24.camel@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Jan 18, 2010 at 03:04:23PM -0500, Ken McDonell wrote:
> Andrew,
> 
> Thanks for this ... it addresses a long-standing annoyance.
> 
> However, apart from the "it only works with flex" issue that I worked
> around in a slightly different way, there are some more serious problems
> with this patch ...
> 
> 1. does not honour the -i and -e flags
> 2. does not handle initial reading from .dbpmdarc if it exists (and the
> associated change in prompt)
> 3. loops forever, i.e. does not exit when ^D read from tty stdin or EOF
> encountered on file/pipe stdin

I didn't take enough time to really understand how that operated, guess
I'm guilty of hit-n-run patching.

I was working under the assumption that your flex functions were going
to getc from whatever buffer I gave them but that doesn't seem to be the
case.

The attached patch should address all three of the problems raised.

> 
> I suspect the readline change really needs to go into dbpmdaFlexInput()
> in lex.l and call yypush_buffer_state() and yypop_buffer_state(). This
> would also make it easier to localize them to be for flex only.
> 

Readline gives back the entire string after any command line editing,
etc, has completed so I'm using that string as an input buffer to feed
your getc function.

> I also suspect the configure.in changes need rework to handle the
> possible (?) case where readline() is in libc, not libreadline ... which
> in the previous patch (but not this one) was checked for in
> configure.in, but did not set any variables there ... I fixed this by
> separating HAVE_READLINE from lib_for_readline.

Yes, I'll now rely on HAVE_READLINE in the sources and use lib_for_readline
& lib_for_curses in builddef.  HAVE_LIBREADLINE goes away.

> 
> Once this is clean for Linux (and I'm guessing Solaris is checked out by
> you guys) we'll need to be sure it builds cleanly on Windows (no idea if
> readline() is there) and Mac OS X (where the shipped readline() is
> apparently broken and without a man page, but the current one from GNU
> can be installed).

Is anyone out there able to test for Mac OS X or Windows?  I have
Linux (Kubuntu 9.10) and (Open)Solaris operating correctly.

> 
> Oh, the joy ...

Indeed.

Andrew Wansink

<snip>

Attachment: readline.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>