From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2851 invoked by alias); 20 Nov 2002 18:36:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2842 invoked from network); 20 Nov 2002 18:36:21 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 20 Nov 2002 18:36:21 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18EbaN-0005Y4-00; Wed, 20 Nov 2002 14:36:35 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18EZhu-0006Hw-00; Wed, 20 Nov 2002 13:36:14 -0500 Date: Wed, 20 Nov 2002 10:36:00 -0000 From: Daniel Jacobowitz To: Richard Sharpe Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: Processing of convenience variables for scripts ... Message-ID: <20021120183613.GA24089@nevyn.them.org> Mail-Followup-To: Richard Sharpe , Andrew Cagney , gdb@sources.redhat.com References: <20021120163549.GA14036@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00275.txt.bz2 On Thu, Nov 21, 2002 at 04:22:53AM +1030, Richard Sharpe wrote: > On Wed, 20 Nov 2002, Daniel Jacobowitz wrote: > > > On Wed, Nov 20, 2002 at 11:32:24AM -0500, Andrew Cagney wrote: > > > >The loop works, but add-symbol-file seems to be called without the > > > >>convenience variables being expanded. > > > >> > > > >>Have it got that right? > > > >> > > > >>If so, what would be the first step to get them expanded? > > > > > > > > > > > >add-symbol-file takes constants, not expressions - so variables are not > > > >expanded. This should probably change but it's not clear how, given > > > >the parser... > > > > > > A quick/dirty hack would be: > > > > > > eval ..... > > > > > > similar to the SH equivalent. I suspect an eval will be needed anyway. > > > > Honestly, I'd rather define the CLI grammar I've been talking about > > than add any more quick hacks. That's a good 6.0 thing to do, clean up > > our CLI a little... > > I have a short-term need and a long-term need. > > I am willing to expend effort on both. Where is the description of this > grammar? In that case, in the short term, it would be worthwhile to implement eval. A simple version would just find any individual word that started with a $ and substitute variables, and end up with something like "eval add-symbol-file $name $addr". The long-term grammar is still entirely in my imagination, alas. It requires: - Examining and recording the syntax of all our existing CLI commands (ouch!). The manual is good but not complete enough IMVHO; people add quirks to functions without documenting them. - Determining which syntax structures we need to preserve and which should go. - Parsing CLI lines before calling the assigned functions, according to some data registered with the handler function. This will involve changing syntax for at least some commands, I expect. I think it's worthwhile but we need to see how invasive it would be. This can be done a bit at a time. I want to get decode_line_1 tamed a bit first... David has made astonishing progress cleaning it up, next will be to characterize its behavior a little better. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer