From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18767 invoked by alias); 10 Jan 2010 05:43:50 -0000 Received: (qmail 18751 invoked by uid 22791); 10 Jan 2010 05:43:49 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 10 Jan 2010 05:43:43 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 12B712BAB7D; Sun, 10 Jan 2010 00:43:42 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Nuj+oarnYEXB; Sun, 10 Jan 2010 00:43:42 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 22A002BAB7C; Sun, 10 Jan 2010 00:43:41 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 33536F5976; Sun, 10 Jan 2010 09:43:28 +0400 (RET) Date: Sun, 10 Jan 2010 05:43:00 -0000 From: Joel Brobecker To: Hui Zhu Cc: Stan Shebs , Tom Tromey , Stan Shebs , Michael Snyder , gdb-patches ml , Eli Zaretskii Subject: Re: [RFC] Let "gcore" command accept a suffix argument Message-ID: <20100110054328.GD2007@adacore.com> References: <4B29018C.6060307@codesourcery.com> <4B3BEDCC.9040103@earthlink.net> <20100106075757.GF24777@adacore.com> <20100109105557.GA2007@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-01/txt/msg00219.txt.bz2 > The current eval doesn't like shell. It just use " point out the > simple string. And if the string is outside out ", eval will try to > convert it to val. OK, I think I understand, now. I see pros and cons to your approach. The approach I suggested (where we only expand convenience variables by detecting the $ sign) is limited because it does not handle expressions in general. Your proposal, does, which is more powerful. If the other maintainers like your syntax, then that'll be fine with me. I have a counter proposal: Have eval follow the same syntax as the printf command. In other words: (gdb) eval "gcore filename.%s.%d", suffix, $counter++ That way, you save yourself having to implement yet-another-parser in GDB, however simple. All you have to do, is factorize the printf_command implementation into a function that stores the string in a memory ui_file, and have both printf_command and eval_command call that function. And we save ourselves the trouble of have to explain the syntax followed by the eval command, as it is identical to the syntax used by the printf command. How does that sound? -- Joel