[RFA 0/3] Allow the user to define default leading args for commands and aliases
Sun Aug 4 16:37:00 GMT 2019
On Wed, 2019-07-24 at 10:15 -0600, Tom Tromey wrote:
> > > > > > "Philippe" == Philippe Waroquiers <firstname.lastname@example.org> writes:
> Philippe> Allow the user to define default leading args for commands and aliases.
> Philippe> This patch series implements, tests and documents the following commands:
> Thank you for the patches.
> Philippe> set leading-args COMMAND [= LEADING-ARGS...]
> Philippe> show leading-args [COMMAND]
> Philippe> set enable-leading-args [on|off]
> Philippe> show enable-leading-args
> Philippe> It also changes the alias command to be:
> Philippe> alias [-a] [--] ALIAS = COMMAND [= LEADING-ARGS...]
> I don't really like the "leading args" approach, but I've put off
> responding to this because I wasn't sure how to articulate my
> However, I never did come up with a really good way to talk about it.
> Partly, I think, the feature seems obscure. It's preferable, in my
> view, to continue the approach gdb already takes; namely, adding "set"
> commands to affect the behavior of commands when desirable.
IMO, the "set <some setting>" commands and "set leading-args"
have 2 different objectives:
* "set <some setting>" defines a specific setting that changes
the behavior of a command. Since Pedro's cli option framework,
settings can have equivalent command args.
* "set leading-args" allows to define default arguments for
It is not very clear to me how to do the second objective with
> On the related commands:
> What is the rationale for "set enable-leading-args"? This seems truly
'set leading-args' allows to define default arguments to the "standard"
gdb commands (such as "backtrace").
So, 'set enable-leading-args off' allows to go back to the default behavior
of such standard commands.
It typically would be used in the "with" command, e.g.:
with enable-leading-args off -- backtrace
Now, this is only useful if we keep the functionality to define default
leading-args for standard GDB commands.
If "set leading-args" is really too obscure, we can just keep the
"alias" part of this patch.
> For "alias", I don't see why the second "=" is required. "alias" would
> be better if it just allowed arguments without special syntax.
> On that topic you wrote:
> Philippe> Also, an '=' character must be specified in the alias command before
> Philippe> the LEADING-ARGS for consistency with set leading-args.
> Philippe> This also ensures that the user cannot type a wrong command name
> Philippe> that would be interpreted as leading args and/or cause 'mismatch'
> Philippe> of length between ALIAS and COMMAND
> I don't really see this as a big concern. Presumably someone would
> notice if their alias did not work properly.
Ok, I will modify the patch to remove the need for this second "=".
If ever we see in the future that (sometimes) an "=" is needed to
avoid the confusion between a leading argument and a command name, we can
always modify the "alias" command to optionally accept an "=" to separate
the COMMAND from its arguments.
More information about the Gdb-patches