Re: implementing eval command

[Michael Snyder <msnyder@specifix.com>]

On Sat, 2008-02-16 at 09:36 +0200, Yakov Lerner wrote:
> On Fri, Feb 15, 2008 at 7:58 PM, Michael Snyder <msnyder@specifix.com> wrote:
> > Moving this to "gdb" list, since it is not a patch.
> >
> >
> >
> >  On Thu, 2008-02-14 at 18:18 +0200, Yakov Lerner wrote:
> >  > I'd like to make a patch that implements eval command, as follows.
> >  > I have following idea to implement eval simply:
> >  > Syntax of eval will be similar to the syntax of 'printf' command:
> >  >          eval "string with %..." comma-separated-expressions
> >  > Implementation relies on existing printf_command() function,
> >  > by rewriting printf_command into pair of functions, one that computes
> >  > result of printf as allocated string; both printf_command and eval_command
> >  > will use compute_printf() function.
> >  > What do you think ?
> >
> >  Hmmm, that would be one way of getting around the
> >  limitations of some commands that can't accept expressions
> >  as arguments (mentioned in another thread).
> >
> >  What do you see as the context for this eval command?
> >  How do you imagine it will be used?
> 
> Apparently, the capability to insert variable into arbitrary part of
> gdb command is missing in gdb. I hit this several days ago when I needed
> to make a script that uses 'thread apply $num where' to a subset of threads
> in a program that had hundreds of threads and I was told on the list that this
> is impossible.

Oh yes, that was the thread I was thinking about.

> I also see other requests for eval command on the mailing list archive.
> So, instead of enriching just 'thread apply' command to accept variable
> (or maybe parenthesized expression) I thought it's much more generic
> to have eval command in the end.
> 
> I thought about easy way to implement it, and then I got idea of using
> the print-like format and comma-separated arg list.

Cool, well, personally I think this is a very interesting idea.
With the printf format, it should be possible to construct
fairly complex commands.