Re: [patch] python prompt additions at first prompt.

[Phil Muldoon <pmuldoon at redhat dot com>]

Matt Rice <ratmice@gmail.com> writes:

> On Mon, Aug 1, 2011 at 2:50 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>> Matt Rice <ratmice@gmail.com> writes:
>>
>>> little bug with the new python prompt stuff, the prompt_hook doesn't
>>> take effect until the second prompt.
>>
>> Thanks for doing this. ÂThis looks fine to me, apart from one question.
>>
>> For tests, there are prompt tests in the python.exp file for prompt
>> substitutions. ÂFor passing arguments to GDB at start-up, see usage of
>> $GDBFLAGS in the testsuite.
>
> I'd tried that, but didn't have much luck,
> i'll give it another shot.


Look at gdb.base/args.exp

You may not be declaring GDBFLAGS as global.


>> display_gdb_prompt removes any handler that is present, and then
>> installs a handler. ÂAs this is the first prompt, the above code does
>> not (because there could not have been a handler installed). ÂI think
>> attempting to remove a handler that does not exist just results in a
>> NOOP, but it is worth checking. ÂI know very little about readline,
>> however. ÂSo my question is: with GDB's copy of readline, is this okay?
>
> Yes, the effect of it seems to turn zero's into zero's.
> by my reading and valgrind, it seems fine,
>
> the documentation doesn't specify one way or the other though.
>
> If it is deemed not OK, it needs to be handled in display_gdb_prompt regardless,
> because gdb -ex 'set editing off' ' followed by a 'set editing on', at
> the gdb prompt, results in 2 calls to _remove before the callback is
> installed
> from display_gdb_prompt, and change_line_handler.

I'm fine with this, display_gdb_prompt has been around since 1999 I
think, and it has not failed in those years.  I think you did a
reasonable analysis.

Cheers,

Phil