From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12764 invoked by alias); 9 Feb 2009 01:53:02 -0000 Received: (qmail 12753 invoked by uid 22791); 9 Feb 2009 01:53:02 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,FB_WORD1_END_DOLLAR,J_CHICKENPOX_33,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Feb 2009 01:52:55 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n191qnqT008579 for ; Mon, 9 Feb 2009 01:52:49 GMT Received: from rv-out-0708.google.com (rvbl33.prod.google.com [10.140.88.33]) by zps37.corp.google.com with ESMTP id n191qkHi019210 for ; Sun, 8 Feb 2009 17:52:47 -0800 Received: by rv-out-0708.google.com with SMTP id l33so1666461rvb.58 for ; Sun, 08 Feb 2009 17:52:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.226.14 with SMTP id y14mr3399397rvg.153.1234144366673; Sun, 08 Feb 2009 17:52:46 -0800 (PST) In-Reply-To: References: Date: Mon, 09 Feb 2009 01:53:00 -0000 Message-ID: Subject: Re: RFC: add ability to "source" Python code From: Doug Evans To: Eli Zaretskii Cc: tromey@redhat.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00197.txt.bz2 On Sat, Feb 7, 2009 at 8:08 PM, Eli Zaretskii 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 :-)]