Re: [RFC] Let "gcore" command accept a suffix argument

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Michael" == Michael Snyder <msnyder@vmware.com> 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