From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15316 invoked by alias); 30 Nov 2009 17:02:08 -0000 Received: (qmail 15055 invoked by uid 22791); 30 Nov 2009 17:02:07 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Nov 2009 17:02:01 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAUH1xWf028260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Nov 2009 12:01:59 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAUH1xt0000369; Mon, 30 Nov 2009 12:01:59 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id nAUH1wvH031578; Mon, 30 Nov 2009 12:01:58 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id BC41037818D; Mon, 30 Nov 2009 10:01:57 -0700 (MST) From: Tom Tromey To: Michael Snyder Cc: gdb@sourceware.org Subject: Re: [RFC] Let "gcore" command accept a suffix argument References: <4B11DA3C.3000203@vmware.com> Reply-To: tromey@redhat.com Date: Mon, 30 Nov 2009 18:44:00 -0000 In-Reply-To: <4B11DA3C.3000203@vmware.com> (Michael Snyder's message of "Sat, 28 Nov 2009 18:19:40 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00220.txt.bz2 >>>>> "Michael" == Michael Snyder writes: Michael> I can't find the reference message, but I have a recollection Michael> about somebody asking why some gdb command (may have been 'gcore') Michael> couldn't accept a gdb internal variable so that the filename could Michael> in effect be "computed", or disambiguated, to avoid overwriting. It isn't just gcore. This lack of reflectivity comes up every week, for different commands, on the gdb irc channel. Our standard answers are (1) use Python, and (2) you can do it more horribly using set logging and shell. Michael> 1) So -- what if 'gcore' were to accept an optional second Michael> argument which, if present, would be treated as an integer and Michael> suffixed to the gcore filename? I don't like it very much, I think because it is a specific solution to a general problem. Michael> Yes, I know, we could do the same thing with Python, but Michael> I'm not convinced that that is an argument against doing it Michael> stand alone (maybe for users who don't want to learn python). I'm not that sympathetic to users who don't want to learn about the facilities that gdb provides. That said, presumably some versions of gdb won't enable python, and it would make sense to provide some solution to those users as well. As a counter-proposal, consider an "eval" command. It would substitute any $foo in its argument before invoking the real command. Your example would be: set $a = 0 eval gcore foo.$a set $a = $a + 1 A "$$" in the argument would be converted to a single "$", so users could also defer convenience variable evaluation when needed. "eval" itself isn't more than a few lines of Python ;) Tom