Re: [RFC] info threads takes an argument

[Tom Tromey <tromey@redhat.com>]

>>>>> "Michael" == Michael Snyder <msnyder@vmware.com> writes:

Michael>  static void
Michael>  info_threads_command (char *arg, int from_tty)
[...]
Michael> +      int tmp_tid
Michael> +	= (int) parse_and_eval_long (scan_expression_with_cleanup (&arg,
Michael> +								   NULL));

parse_and_eval_long means that expressions will be accepted here.  But
then I think it will do the wrong thing if you actually pass multiple
IDs -- I think it will syntax error instead of parsing each separately.

I'd suggest just parsing out an integer and using atoi or the like.
(I'm not sure if there is already a convenience function for this -- I'm
always a little surprised at how few argument-parsing convenience
functions there are for the CLI.)


I like "thread find", it seems handy.

Matching both the ID and the target PID means that using numbers here
will be over-eager.  Why match the ID?  "info thread ID" seems good
enough.

Michael> +  add_info ("threads", info_threads_command, 
Michael> +	    _("Display currently known threads.\n\
Michael> +Usage: info threads [ID [ID]...]\n\

I think it is more typical to write this as:

Usage: info threads [ID]...

Michael> +  add_cmd ("find", no_class, thread_find_command, _("\
Michael> +Find thread ids with a name, target pid, or extra info matching REGEXP."),
Michael> +	   &thread_cmd_list);

How about a Usage here, too?  Like:

Find threads that match a regular expression.
Usage: thread find REGEXP
This command will display all the threads whose name, target PID, or
extra info matches REGEXP.

Michael> +* GDB has a new command: "thread find [regexp]".

I'd make regexp all upper-case, in keeping with a GNU documentation
convention.

Tom