Re: [RFA 01/10] Rationalize "backtrace" command line parsing

[Pedro Alves <palves@redhat.com>]

I noticed now that this series is still pending.

On 04/25/2017 08:41 PM, Tom Tromey wrote:
> The backtrace command has peculiar command-line parsing.  In
> particular, it splits the command line, then loops over the arguments.
> If it sees a word it recognizes, like "full", it effectively drops
> this word from the argument vector.  Then, it pastes together the
> remaining arguments, passing them on to backtrace_command_1, which in
> turn passes the resulting string to parse_and_eval_long.
> 
> The documentation doesn't mention the parse_and_eval_long at all, so
> it is a bit of a hidden feature that you can "bt 3*2".  The strange
> algorithm above also means you can "bt 3 * no-filters 2" and get 6
> frames...
> 

Funny.

> This patch changes backtrace's command line parsing to be a bit more
> rational.  Now, special words like "full" are only recognized at the
> start of the command.
> 
> This also updates the documentation to describe the various bt options
> individually.
> 
> ChangeLog
> 2017-04-25  Tom Tromey  <tom@tromey.com>
> 
> 	* stack.c (backtrace_command): Rewrite command line parsing.

LGTM.

It might be good to clarify "help bt", to show something around:

  Usage: backtrace [QUALIFIERS]... COUNT


I'd support deprecating the existing non-hyphenated qualifiers,
and start supporting hyphenated options:

  bt -full -no-filters -whatever-new-option -- COUNT

Thanks,
Pedro Alves