Re: naming command arguments

[Michael Snyder <msnyder at redhat dot com>]

Andrew Cagney wrote:
> 
> > I've been talking to some GDB users who are frustrated with some of
> > GDB's command syntax.  My understanding is that optional command
> > arguments must be the last possible arguments, and they get dropped off
> > right to left.  The problem is that some GDB commands have multiple
> > arguments, all of which make sense to be optional, but in no particular
> > order.
> >
> > So, for instance, the restore command looks something like:
> >
> >       restore FILENAME [OFFSET [START [STOP]]]
> >
> > In this case, if you only want to specify the START argument, your
> > forced to give OFFSET argument.
> >
> > They're suggestion, which seems to make sense to me, is to introduce the
> > concept of named parameters for GDB commands.  So, in my previous
> > example, they could simply write...
> >
> >       restore FILENAME start:VALUE
> >
> > ...and let GDB make reasonable assumptions about OFFSET and STOP
> >
> > How do people feel about introducing these kinds of arguments to certain
> > GDB commands (like restore)?
> 
> For this specific case, how does one differentiate between:
> 
>         start:1
> 
> the source and line specification and:
> 
>         start:1
> 
> the start:VALUE?

For this specific case, the command doesn't accept line specs.
Only integer expressions interpretted as addresses.


> GDB desperatly needs a command line syntax that better allows the
> specification of optional information but it needs to be chosen very
> carefully.
> 
> Other options to consider:
> 
>         restore/start:VALUE FILE
>         restore --start=VALUE FILE
> 
> etc.
> 
> Andrew