Processing of convenience variables for scripts ...

Processing of convenience variables for scripts ...

[Richard Sharpe]

Hi,

The following script does not seem to work:

define load-ko-syms
   path ./freebsd_46_i386/debug/export/kernel
   set $file = linker_files.tqh_first
   set $file = $file->link.tqe_next
   if ($file == 0)
        printf "No klds to load symbols for\n"
   else
        while ($file != 0)
                add-symbol-file $file->filename ($file->address + 
$file->text_offs)
                printf "Loaded symbols for %s\n", $file->filename
                set $file = $file->link.tqe_next
        end
   end
end

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?

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com

Re: Processing of convenience variables for scripts ...

[Daniel Jacobowitz]

On Wed, Nov 20, 2002 at 07:42:04PM +1030, Richard Sharpe wrote:
> Hi,
> 
> The following script does not seem to work:
> 
> define load-ko-syms
>    path ./freebsd_46_i386/debug/export/kernel
>    set $file = linker_files.tqh_first
>    set $file = $file->link.tqe_next
>    if ($file == 0)
>         printf "No klds to load symbols for\n"
>    else
>         while ($file != 0)
>                 add-symbol-file $file->filename ($file->address + 
> $file->text_offs)
>                 printf "Loaded symbols for %s\n", $file->filename
>                 set $file = $file->link.tqe_next
>         end
>    end
> end
> 
> 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...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Processing of convenience variables for scripts ...

[Andrew Cagney]

> 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.

Andrew

Re: Processing of convenience variables for scripts ...

[Daniel Jacobowitz]

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...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Processing of convenience variables for scripts ...

[Richard Sharpe]

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?

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com

Re: Processing of convenience variables for scripts ...

[Daniel Jacobowitz]

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

Re: Processing of convenience variables for scripts ...

[Eli Zaretskii]

On Wed, 20 Nov 2002, Daniel Jacobowitz wrote:

>   - 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.

If you find undocumented features, please tell what they are.  Let's at 
least have a list of them.

TIA

Re: Processing of convenience variables for scripts ...

[Fernando Nasser]

Daniel Jacobowitz wrote:
> 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".
> 

Seems useful to me, and probably not difficult to implement.



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Processing of convenience variables for scripts ...

[Doug Evans]

Fernando writes:
 >>Daniel Jacobowitz wrote:
 >>
 >> 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".
 >
 > Seems useful to me, and probably not difficult to implement.

add-symbol-file takes a file name as the first argument and
you can't store strings (of any kind) in convenience variables.

I haven't checked FSF sources in the last few months,
maybe things have improved.  If so great.  If not, how would this work?

Re: Processing of convenience variables for scripts ...

[Daniel Jacobowitz]

On Sun, Dec 08, 2002 at 11:36:22AM -0800, Doug Evans wrote:
> Fernando writes:
>  >>Daniel Jacobowitz wrote:
>  >>
>  >> 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".
>  >
>  > Seems useful to me, and probably not difficult to implement.
> 
> add-symbol-file takes a file name as the first argument and
> you can't store strings (of any kind) in convenience variables.
> 
> I haven't checked FSF sources in the last few months,
> maybe things have improved.  If so great.  If not, how would this work?

This is true.  One problem at a time - numbers first.  I have some
ideas, but I won't have a chance to work on this until next weekend.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Processing of convenience variables for scripts ...

[Doug Evans]

Daniel Jacobowitz writes:
 > > add-symbol-file takes a file name as the first argument and
 > > you can't store strings (of any kind) in convenience variables.
 > > 
 > > I haven't checked FSF sources in the last few months,
 > > maybe things have improved.  If so great.  If not, how would this work?
 > 
 > This is true.  One problem at a time - numbers first.  I have some
 > ideas, but I won't have a chance to work on this until next weekend.

Well, ...

If one is going to do a redesign of things one should at least
think about all the known issues before doing any coding.
[I'm sure there's no news there.]

Do we at least know how we're going to handle strings,
and what compatibleness with existing usage we're going to break?

btw, while doing a redesign of the cli is laudable,
the more I work with gdb's command structure the more I like its simplicity.
I wouldn't mind regularizing the syntax of arguments such
that one can know one can always use buildargv (or some such).
And providing an sscanf-like routine that *_command fns can call
would also be useful.  Beyond that I dunno ....

Re: Processing of convenience variables for scripts ...

[Doug Evans]

Andrew writes:
 >> 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 .....

Can someone point me to threads on `eval'?
My poor eyes can't find one.

Re: Processing of convenience variables for scripts ...

[Richard Sharpe]

On Sun, 8 Dec 2002, Doug Evans wrote:

> Andrew writes:
>  >> 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 .....
> 
> Can someone point me to threads on `eval'?
> My poor eyes can't find one.

I think that the intent was that someone implement eval. I can't find an 
existing one. Maybe my eyes are bad as well.

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com

eval [was Re: Processing of convenience variables for scripts ...]

[Doug Evans]

Richard Sharpe writes:
 > On Sun, 8 Dec 2002, Doug Evans wrote:
 > 
 > > Andrew writes:
 > >  >> 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 .....
 > > 
 > > Can someone point me to threads on `eval'?
 > > My poor eyes can't find one.
 > 
 > I think that the intent was that someone implement eval. I can't find an 
 > existing one. Maybe my eyes are bad as well.

I recall a message from Fernando (I think) refering to the existing
threads on eval, so I was wondering where they were.

What about a $()-like command akin to bash?
Maybe spelled $`` (backquote also from bash and because $` is
a syntax that doesn't collide with anything).
It's very useful to be able to run a command and have the result be used
in another command.

For add-symbol-file, one might do

add-symbol-file $`printf %s, $name` blah...

$`` is useful regardless of how the cli is rewritten,
though perhaps in this example it's more clumsy than just $name.
OTOH, there's enormous flexibility.
It does require commands that are used with it to properly
send their output through something that can be captured in a string,
but that's a good thing for them to do anyway.

Processing of convenience variables for scripts ...

[Richard Sharpe]

Hi,

In looking at this issue, it seems that much of the existing code that 
deals with variables is centered around printing:

   value_print (var->value, gdb_stdout, 0, Val_pretty_default);

While it seems that I could mess with providing new functions for a stream 
structure that I could retrieve strings from, is there a simpler way.

I envision something like 

  var1 = value_to_string (var->value);

And then construct a new command, and pass it through the standard routine 
that processes commands. 

However, it seems that things are not that simple :-)

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com

Re: Processing of convenience variables for scripts ...

[Daniel Jacobowitz]

On Fri, Dec 06, 2002 at 08:57:07AM -0800, Richard Sharpe wrote:
> Hi,
> 
> In looking at this issue, it seems that much of the existing code that 
> deals with variables is centered around printing:
> 
>    value_print (var->value, gdb_stdout, 0, Val_pretty_default);
> 
> While it seems that I could mess with providing new functions for a stream 
> structure that I could retrieve strings from, is there a simpler way.
> 
> I envision something like 
> 
>   var1 = value_to_string (var->value);
> 
> And then construct a new command, and pass it through the standard routine 
> that processes commands. 
> 
> However, it seems that things are not that simple :-)

You're looking in the wrong place, I'd say.  Look in parse.c for the
call to:
 lookup_internalvar (copy_name (str) + 1)

That said, I'm not worried about implementing this as much as I am
designing what it "ought" to look like.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Processing of convenience variables for scripts ...

[Fernando Nasser]

Daniel Jacobowitz wrote:
> 
> That said, I'm not worried about implementing this as much as I am
> designing what it "ought" to look like.
> 

For me just:

eval command args... ${something} more args...

where the value of ${something} is blah

causes the following command to be executed

command args... blahh more args...


eval just expands the variable to create the real command to be excuted 
and calls execute_command() with it.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Processing of convenience variables for scripts ...

[Richard Sharpe]

On Fri, 6 Dec 2002, Fernando Nasser wrote:

> Daniel Jacobowitz wrote:
> > 
> > That said, I'm not worried about implementing this as much as I am
> > designing what it "ought" to look like.
> > 
> 
> For me just:
> 
> eval command args... ${something} more args...
> 
> where the value of ${something} is blah
> 
> causes the following command to be executed
> 
> command args... blahh more args...
> 
> 
> eval just expands the variable to create the real command to be excuted 
> and calls execute_command() with it.

This sounds like a simple short-term solution while we wait on a more 
general method where all commands can take expressions of any type :-)

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com

Re: Processing of convenience variables for scripts ...

[Fernando Nasser]

Richard Sharpe wrote:> On Fri, 6 Dec 2002, Fernando Nasser wrote:
> 
> 
>>Daniel Jacobowitz wrote:
>>
>>>That said, I'm not worried about implementing this as much as I am
>>>designing what it "ought" to look like.
>>>
>>
>>For me just:
>>
>>eval command args... ${something} more args...
>>
>>where the value of ${something} is blah
>>
>>causes the following command to be executed
>>
>>command args... blahh more args...
>>
>>
>>eval just expands the variable to create the real command to be excuted 
>>and calls execute_command() with it.
> 
> 
> This sounds like a simple short-term solution while we wait on a more 
> general method where all commands can take expressions of any type :-)
> 

Why we would want that?  Are you thinking of any specific example where this 
could be useful?




-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Processing of convenience variables for scripts ...

[Daniel Jacobowitz]

On Fri, Dec 06, 2002 at 05:53:31PM -0500, Fernando Nasser wrote:
> Richard Sharpe wrote:> On Fri, 6 Dec 2002, Fernando Nasser wrote:
> >
> >
> >>Daniel Jacobowitz wrote:
> >>
> >>>That said, I'm not worried about implementing this as much as I am
> >>>designing what it "ought" to look like.
> >>>
> >>
> >>For me just:
> >>
> >>eval command args... ${something} more args...
> >>
> >>where the value of ${something} is blah
> >>
> >>causes the following command to be executed
> >>
> >>command args... blahh more args...
> >>
> >>
> >>eval just expands the variable to create the real command to be excuted 
> >>and calls execute_command() with it.
> >
> >
> >This sounds like a simple short-term solution while we wait on a more 
> >general method where all commands can take expressions of any type :-)
> >
> 
> Why we would want that?  Are you thinking of any specific example where 
> this could be useful?

Well, it seems much more logical to me... right now some commands
accept $var and some don't.  The inconsistency gets on my nerves when I
hit it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Processing of convenience variables for scripts ...

[Richard Sharpe]

On Fri, 6 Dec 2002, Daniel Jacobowitz wrote:

> On Fri, Dec 06, 2002 at 08:57:07AM -0800, Richard Sharpe wrote:
> > Hi,
> > 
> > In looking at this issue, it seems that much of the existing code that 
> > deals with variables is centered around printing:
> > 
> >    value_print (var->value, gdb_stdout, 0, Val_pretty_default);
> > 
> > While it seems that I could mess with providing new functions for a stream 
> > structure that I could retrieve strings from, is there a simpler way.
> > 
> > I envision something like 
> > 
> >   var1 = value_to_string (var->value);
> > 
> > And then construct a new command, and pass it through the standard routine 
> > that processes commands. 
> > 
> > However, it seems that things are not that simple :-)
> 
> You're looking in the wrong place, I'd say.  Look in parse.c for the
> call to:
>  lookup_internalvar (copy_name (str) + 1)

OK, but the problem there is that lookup_internalvar returns a struct 
internalvar *. While there is a function value_of_internal var (also in 
values.c), it returns a struct value *.

I need the value of an internal var as something approximating a C 
string, and the only functions that deal with displaying the value of an 
internal variable (or any variable, it seems) is value_print, which wants 
a struct ui_file *. Or so it seems?

Have the recreational drugs finally proven too much, or have I got it 
right here?

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com