Tom Tromey wrote:
>>>>>> "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.)

OK.

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

"info thread" will only match the gdb thread id (small counting 
integer).  "thread find" will match the PID.


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

OK, changes made, and committed as below (with a new testsuite test).