naming command arguments

naming command arguments

[Anthony Green]

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)?

AG

Re: naming command arguments

[Andrew Cagney]

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

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

Re: naming command arguments

[Anthony Green]

On Thu, 2002-07-25 at 16:23, Andrew Cagney wrote:
> For this specific case, how does one differentiate between:
> 
> 	start:1
> 
> the source and line specification and:
> 
> 	start:1
> 
> the start:VALUE?

Just by context.  And in the case that the command has both optional
source location and numerical arguments _and_ the user has a file name
which clashes with an argument name, you just let the user disambiguate
by using multiple ':', so 

	start::1

doesn't identify a source location because the user doesn't have a
"start:" file.  This seems to be a reasonable solution to what I imagine
will be a very rare problem. 

AG

Re: naming command arguments

[Michael Snyder]

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

Re: naming command arguments

[Andrew Cagney]

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

What of start::foo? (I think I've got my C++ syntax right :-)

Andrew

Re: naming command arguments

[Daniel Jacobowitz]

On Mon, Jul 29, 2002 at 11:41:20AM -0400, Andrew Cagney wrote:
> >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.
> 
> What of start::foo? (I think I've got my C++ syntax right :-)

I think that we should actually come up with a unified command line
syntax, probably breaking compatibility with existing commands, and
implement it for 6.0.  If we continue to add little hacks around this
the line parsing is just going to get worse and worse.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: naming command arguments

[Fernando Nasser]

Anthony,

We have already detected that the current GDB CLI has been stretched
to its limits and the we need something more powerful.  We all want a
real script language for GDB.  The official choice for this language
(accordingly to FSF) is Guile but we wanted to make it possible for 
people to add their script language of choice.  Libgdb and the MI 
were expected to help us to achieve that.  Unfortunately this can
still take some time.

Anyway, trying to fix the CLI at large will probably create more 
headaches than benefits.  But we can try and do something for a few
cases where it is really a big impediment (like your example).

IMO the only plausible options are the two ones listed by Andrew.
  
Regards,
Fernando


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

Re: naming command arguments

[Andrew Cagney]

> On Mon, Jul 29, 2002 at 11:41:20AM -0400, Andrew Cagney wrote:
> 
>> >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.
> 
>> 
>> What of start::foo? (I think I've got my C++ syntax right :-)
> 
> 
> I think that we should actually come up with a unified command line
> syntax, probably breaking compatibility with existing commands, and
> implement it for 6.0.  If we continue to add little hacks around this
> the line parsing is just going to get worse and worse.

We don't have much choice.  As they say, if it hurts it must be good for 
you....

It needs to be considered carefully though.

Andrew

Re: naming command arguments

[Anthony Green]

On Tue, 2002-07-30 at 17:43, Fernando Nasser wrote:
> We have already detected that the current GDB CLI has been stretched
> to its limits and the we need something more powerful.  We all want a
> real script language for GDB.  The official choice for this language
> (accordingly to FSF) is Guile but we wanted to make it possible for 
> people to add their script language of choice. 

Like REXX?... :-)

http://groups.google.com/groups?q=rexx+gdb&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=742315756snx%40roboco.UUCP&rnum=1

(sorry - but this just reminded me of my first gdb hacking experience
many years ago...)

AG