"thread apply 1 -- -" vs "frame apply level 0 -- -"

With the following patch, we'll be able to explicitly tell "thread
apply" where options end, using the "--" delimiter.  A test added by
that patch caught a pre-existing inconsistency:

 (gdb) thread apply 1 -- -
 Invalid thread ID: -

 (gdb) frame apply level 0 -- -
 #0  main () at threads.c:55
 Cannot enable the TUI when output is not a terminal

Above, "thread apply" did not try to run the command, while "frame
apply level" did.  ("-" is a valid TUI command.)

That "-" is past "--", so it should have not been confused with an
invalid TID, in the "thread apply" case.

That error actually doesn't come from the TID parser, but instead from
thread_apply_command directly.

So that error/check needs tweaking.  The next question is what to
tweak it to.

"-" is actually a valid TUI command:

 (gdb) help -
 Scroll window backward.
 Usage: - [WIN] [N]

(gdb) frame apply level 0 -- -
#0  main () at threads.c:55
Cannot enable the TUI when output is not a terminal

While I don't imagine it being useful to use that "-" command with
"thread apply" or "frame apply level", the fact is that you can use it
with "frame apply level", but not with "thread apply".  And since it's
an actual command, pedantically it seems right to allow it.

That's what this commit does.

Note: simply removing the "isalpha" check regresses
gdb.multi/tids.exp -- see related commit 3f5b7598805c.

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <palves@redhat.com>

	* thread.c (thread_apply_command): Check for invalid TID with
	isdigit instead of !isalpha.

1 files changed, 1 insertions, 1 deletions

diff --git a/gdb/thread.c b/gdb/thread.c
index 24906fa7d60..ea87f51c6e6 100644
--- a/gdb/thread.c
+++ b/gdb/thread.c
@@ -1583,7 +1583,7 @@ thread_apply_command (const char *tidlist, int from_tty)
   if (*cmd == '\0')
     error (_("Please specify a command following the thread ID list"));
 
-  if (tidlist == cmd || !isalpha (cmd[0]))
+  if (tidlist == cmd || isdigit (cmd[0]))
     invalid_thread_id_error (cmd);
 
   scoped_restore_current_thread restore_thread;