Re: [PATCH 2/2] gdb: Allow parenthesis to group arguments to user-defined commands

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Philippe Waroquiers <philippe.waroquiers@skynet.be> [2018-08-28 22:28:57 +0200]:

> On Tue, 2018-08-28 at 19:43 +0100, Andrew Burgess wrote:
> > * Tom Tromey <tom@tromey.com> [2018-08-28 09:53:52 -0600]:
> > 
> > > > > > > > "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
> > > 
> > > Andrew> So, my suggestion deliberately avoids using quotes or backslashes as
> > > Andrew> these are bogged down in the existing code.  And using (...) is fairly
> > > Andrew> intuitive given GDBs C like expression handling, personally I'd rather
> > > Andrew> write:
> > > Andrew>     my_command ({unsigned long long} &global_var)
> > > Andrew> than:
> > > Andrew>     my_command {unsigned\ long\ long}\ &global_var
> > > 
> > > FWIW I tend to agree with your logic here.
> > > 
> > > User-defined argument parsing is broken (and I think there's at least
> > > one bug in bugzilla about this), but at the same time, making breaking
> > > changes seems unfriendly.  Your approach doesn't seem to be breaking
> > > anything that is likely to be actually used.
> 
> I do not think a \ followed by a space will create a lot of incompatibilities.
> i
> .e. that someone would type
>     some_user_defined_command  a\ b
> to give 2
> different args to the command.

No, and what they get at the moment is a single argument, which is:

    a\ b

including the backslash and the space.  Is this correct, or useful?  I
suspect not, but my instinct in these cases is not to mess with things
without good reason, and I didn't have a good reason.

> 
> For single quotes:  it is unlikely that someone types something like
>    some_user_defined_command 'abc def'
> and was expecting the user defined command to receive two args.

I agree, and what they get right now is:

    'abc def'

including the quotes.

> What is however a lot more likely is
>    some_user_defined_command 'a'
> and this command expects to receive a character value.

Which is more or less what you get:

    'a'

> So, yes, single quotes has more potential to create
> incompatibilities.

I guess that depends on what you're proposing the argument should
evaluate too.

> 
> On the downside, quoting with parenthesis is something very peculiar
> (is there some other tool/shell/... using this convention ?).

I guess I never saw it as quoting, just grouping an expression
together.  I think I see GDB as mostly consuming C like expressions,
which is why using () seemed natural enough. Coincidentally the users
I'm working with initially tried () too (without prompting from me) so
my focus group of 2 all agreed with me ;-)

> 
> And from a previous discussion with Pedro, he indicated that
> some commands in gdb already are using single quotes.
> The 'Not sure' below is a quote of Pedro :), replying to a suggestion
> I gave to let the user tell explicitly if an arg was quoted or not.
>    >   * have a way to (explicitely) quote an argument e.g.
>    >       info var  -Qt 'long int'  regexpofsomevars
>    >     where -Q indicates that the next "value argument" is
>    >     explicitely quoted.
> 
>    Not sure we need that -Q.  We can support optional quotes, and
>    tell users to add quotes if necessary?  That's what we've done
>    since forever in linespecs and expressions, for example.
> 
> It is based on this that I used single quotes in the 
>   info var/func/arg/local -t TYPEREGEXP NAMEREGEXP
> patch.
> 
> > Given that the argument passing for user-defined functions is pretty
> > self contained we could, conceivably, implement a whole new system and
> > have a switch to select between them...  the existing code does seem
> > rather odd.
> > 
> > But ideally, I'd like that to be a project for another day.
> And we also have the 'generalised arg parser' prototype that Pedro has
> in a corner.
> 
> IMO, clearly, what to do is unclear :).

I agree, except I need to figure out some clarity in order to resolve
the real issue I have :)

I think that you're arguing in favour of reworking the argument
passing to user-defined commands.  I'm not entirely sure exactly what
rules you're proposing we adopt though.

Maybe you could help me work through a few examples, in the following
table I've outlined a few examples, and have the following questions:

  [1] What argument(s) would be passed under the new scheme?
  [2] What argument(s) would be passed under the new scheme?
  [3] How would I write {unsigned long} &var to pass this as a single
      argument?  If with quotes, how does this relate to 1 & 2?

  | Input                | Current Arguments(s) | Proposed Argument(s) |
  |----------------------+----------------------+----------------------|
  | a b                  | a                    | a                    |
  |                      | b                    | b                    |
  |----------------------+----------------------+----------------------|
  | "a b"                | "a b"                | [1]                  |
  |----------------------+----------------------+----------------------|
  | 'a b'                | 'a b'                | [2]                  |
  |----------------------+----------------------+----------------------|
  | {unsigned long} &var | {unsigned            |                      |
  |                      | long}                | N/A                  |
  |                      | &var                 |                      |
  |----------------------+----------------------+----------------------|
  | [3]                  |                      |                      |
  |----------------------+----------------------+----------------------|

In general I'm happy to rework this part of GDB, but ideally I'd like
some feedback from a global maintainer that such a change, which might
would break backward compatibility, would be acceptable...

Thanks,
Andrew