Re: RFC: add ability to "source" Python code

[Doug Evans <dje at google dot com>]

On Sat, Feb 7, 2009 at 8:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> However, I don't think I like the idea of GDB barfing if Python
> support is not compiled in.  I think it should simply try to interpret
> the file as GDB scripting commands.

I 3/4 disagree.  :-)

In the case of "source -p foo", I disagree.  This is new functionality
(*1), and silently (or otherwise) interpreting "source -p foo" as gdb
scripts will lead to subsequent breakage if/when python support does
get compiled in.  [That's 1/2 of the 3/4.]

In the case of "source foo.py" I sort of disagree (that's the other 1/4, fwiw).
Technically speaking it's possible that some bloke out there has a
foo.py script that actually is gdb commands, and forcing the script to
be interpreted as python would break that.  It's seems really unlikely
though.

Perhaps "source" could/should also take a -g option to force the
script to be interpreted as gdb commands.  It mightn't be sufficient
to justify breaking an existing "source foo.py" being interpreted as
gdb commands (though I think it is), but it might be reasonable to add
anyway.

[(*1): And if we're worried about breaking existing usage, do we also
need to worry about someone with a script named "-p foo.gdb"?

bash$ cat ./"-p foo.gdb"
echo this is foo\n
bash$ gdb -quiet
(gdb) source -p foo.gdb
this is foo
(gdb) q
7.0.x-beta$

1/2 :-)]