Re: [RFA] candidates for ambiguous command in upper case

Re: [RFA] candidates for ambiguous command in upper case

[Yao Qi]

On 17-01-10 15:25:24, Jerome Guitton wrote:
> If you type an ambiguous command in lower case, gdb tells the command
> is ambiguous and tells you which one could match. If you type the same
> but in upper case, gdb also says it is ambiguous, but shows an empty
> list of commands:
> 
>  (gdb) ex
>  Ambiguous command "ex": exec-file, expression.
>  (gdb) EX
>  Ambiguous command "EX": .
> 

IMO, there is nothing wrong.  There is no command starts from "EX".

In bash, I type "make" and tab, I get,
$ make
make            makeglossaries  makeindex       makeinfo        makejvf         make-ssl-cert   make_strings

If type "MAKE", and type, I get,
$ MAKEDEV

-- 
Yao (齐尧)

Re: [RFA] candidates for ambiguous command in upper case

[Jerome Guitton]

Yao Qi (qiyaoltc@gmail.com):

> IMO, there is nothing wrong.  There is no command starts from "EX".

This is a bit weird to accept upper-case EXEC-FIL then... isn't it?

(gdb) exec-fil
No executable file now.
(gdb) EXEC-FIL
No executable file now.

Re: [RFA] candidates for ambiguous command in upper case

[Simon Marchi]

On 2017-01-10 10:19, Jerome Guitton wrote:
> Yao Qi (qiyaoltc@gmail.com):
> 
>> IMO, there is nothing wrong.  There is no command starts from "EX".
> 
> This is a bit weird to accept upper-case EXEC-FIL then... isn't it?
> 
> (gdb) exec-fil
> No executable file now.
> (gdb) EXEC-FIL
> No executable file now.

I agree that if GDB accepts commands in upper case, the ambiguous 
command message should work accordingly.  The message as it is, with an 
empty list, doesn't make sense.

I also noticed that tab completion was case sensitive, should that be 
fixed as well?

For example,

   (gdb) inf<tab><tab>

shows "inferior  info", but

   (gdb) INF<tab><tab>

shows nothing.  Should it show "inferior  info", or "INFERIOR INFO"?

Re: [RFA] candidates for ambiguous command in upper case

[Jerome Guitton]

Simon Marchi (simon.marchi@polymtl.ca):

> I also noticed that tab completion was case sensitive, should that
> be fixed as well?

I guess so. It seems that it could be changed by a similar patch in
complete_on_cmdlist.

Re: [RFA] candidates for ambiguous command in upper case

[Pedro Alves]

On 01/10/2017 03:28 PM, Simon Marchi wrote:
> On 2017-01-10 10:19, Jerome Guitton wrote:
>> Yao Qi (qiyaoltc@gmail.com):
>>
>>> IMO, there is nothing wrong.  There is no command starts from "EX".
>>
>> This is a bit weird to accept upper-case EXEC-FIL then... isn't it?
>>
>> (gdb) exec-fil
>> No executable file now.
>> (gdb) EXEC-FIL
>> No executable file now.
> 
> I agree that if GDB accepts commands in upper case, the ambiguous
> command message should work accordingly.

Agreed.  I thought that the manual mentioned that gdb accepts
commands in either case, but I can't find it now.

> The message as it is, with an empty list, doesn't make sense.
> 
> I also noticed that tab completion was case sensitive, should that be
> fixed as well?
> 
> For example,
> 
>   (gdb) inf<tab><tab>
> 
> shows "inferior  info", but
> 
>   (gdb) INF<tab><tab>
> 
> shows nothing.  Should it show "inferior  info", or "INFERIOR INFO"?

I think the former.  I.e., show the canonical lowercase.  That
is likely to end up much easier and saner to implement.

I've been playing with completion recently [1], and I've noticed
that

 (gdb) handle sigu<tab>

completes to:

 (gdb) handle SIGU<bell>

 (gdb) handle sig<tab>

Or really:

 (gdb) handle sigu M-?
 SIGURG   SIGUSR1  SIGUSR2  

In my branch I've completely changed how GDB hands over
completion matches to readline, and I've had to make
sure to preserve that behavior, as caught by some test.

[1] - this WIP branch gets rid of the need to quote
      linespecs as in "b 'function(int<tab>" among other things:

  https://github.com/palves/gdb/commits/palves/cp-linespec

Thanks,
Pedro Alves

Re: [RFA] candidates for ambiguous command in upper case

[Jerome Guitton]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

Pedro Alves (palves@redhat.com):

> In my branch I've completely changed how GDB hands over
> completion matches to readline, and I've had to make
> sure to preserve that behavior, as caught by some test.

Interesting! When do you think that this branch would be merged in
master? Still interested in my patch in the meantime? I guess that
the new tests would be useful in any case.

Last version in attachment. There was already a test for "info sysq",
I've added "info T" and "info TERMINA".



[-- Attachment #2: 2017-01-11-cli-decode.diff --]
[-- Type: text/x-diff, Size: 3429 bytes --]

commit 0eec4d84f57d5a214e00f3186f38d3af07584d86
Author: Jerome Guitton <guitton@adacore.com>
Date:   Tue Jan 10 15:10:08 2017 +0100

    [RFA] candidates for ambiguous command in upper case
    
    If you type an ambiguous command in lower case, gdb tells the command
    is ambiguous and tells you which one could match. If you type the same
    but in upper case, gdb also says it is ambiguous, but shows an empty
    list of commands:
    
     (gdb) ex
     Ambiguous command "ex": exec-file, expression.
     (gdb) EX
     Ambiguous command "EX": .
    
    The same issue with completion.
    
      (gdb) inf<tab><tab>
    
    shows "inferior  info", but
    
      (gdb) INF<tab><tab>
    
    shows nothing.
    
    Simple fix in attachment, with an additional test.
    Tested on x86-linux. OK to apply?
    
    gdb/ChangeLog:
    
    	* cli-decode.c (lookup_cmd): case insensitive match when looking
    	up candidates for ambiguous command.
    	(complete_on_cmdlist): Ditto.
    
    gdb/testsuite/ChangeLog:
    
    	* gdb.base/completion.exp: Add tests for completion of upper case
    	commands.

diff --git a/gdb/cli/cli-decode.c b/gdb/cli/cli-decode.c
index d3be93c..dbd874e 100644
--- a/gdb/cli/cli-decode.c
+++ b/gdb/cli/cli-decode.c
@@ -1550,7 +1550,7 @@ lookup_cmd (const char **line, struct cmd_list_element *list, char *cmdtype,
 
 	  ambbuf[0] = 0;
 	  for (c = local_list; c; c = c->next)
-	    if (!strncmp (*line, c->name, amb_len))
+	    if (!strncasecmp (*line, c->name, amb_len))
 	      {
 		if (strlen (ambbuf) + strlen (c->name) + 6
 		    < (int) sizeof ambbuf)
@@ -1800,7 +1800,7 @@ complete_on_cmdlist (struct cmd_list_element *list,
   for (pass = 0; matchlist == 0 && pass < 2; ++pass)
     {
       for (ptr = list; ptr; ptr = ptr->next)
-	if (!strncmp (ptr->name, text, textlen)
+	if (!strncasecmp (ptr->name, text, textlen)
 	    && !ptr->abbrev_flag
 	    && (!ignore_help_classes || ptr->func
 		|| ptr->prefixlist))
diff --git a/gdb/testsuite/gdb.base/completion.exp b/gdb/testsuite/gdb.base/completion.exp
index 4a3ee4b..cae45ae 100644
--- a/gdb/testsuite/gdb.base/completion.exp
+++ b/gdb/testsuite/gdb.base/completion.exp
@@ -30,6 +30,8 @@
 #   "info t foo" no completions
 #   "info t " no completions
 #   "info t" ambiguous ("info target", "info terminal", etc.)
+#   "info T" ambiguous ("info target", "info terminal", etc.)
+#   "info TERMINA" unambiguous (completes to "info terminal")
 #   "info ajksdlfk" no completions
 #   "info ajksdlfk " no completions
 #   "info" " "
@@ -265,6 +267,32 @@ gdb_test_multiple "" "$test" {
     }
 }
 
+set test "complete 'info T '"
+send_gdb "info T \t"
+gdb_test_multiple "" "$test" {
+    -re "^info T \\\x07$" {
+	send_gdb "\n"
+	gdb_test_multiple "" "$test" {
+	    -re "Ambiguous info command \"T \": target, tasks, terminal, threads, tp, tracepoints, tvariables, (type-printers, )?types\\..*$gdb_prompt $" {
+		pass "$test"
+	    }
+	}
+    }
+}
+
+set test "complete 'info TERMINA'"
+send_gdb "info TERMINA\t"
+gdb_test_multiple "" "$test" {
+    -re "^info TERMINA\b\b\b\b\b\b\bterminal $" {
+	send_gdb "\n"
+	gdb_test_multiple "" "$test" {
+	    -re "Inferior's terminal status.*$gdb_prompt $" {
+		pass "$test"
+	    }
+	}
+    }
+}
+
 set test "complete 'info t '"
 send_gdb "info t \t"
 gdb_test_multiple "" "$test" {

Re: [RFA] candidates for ambiguous command in upper case

[Yao Qi]

On 17-01-10 17:00:28, Pedro Alves wrote:
> On 01/10/2017 03:28 PM, Simon Marchi wrote:
> > On 2017-01-10 10:19, Jerome Guitton wrote:
> >> Yao Qi (qiyaoltc@gmail.com):
> >>
> >>> IMO, there is nothing wrong.  There is no command starts from "EX".
> >>
> >> This is a bit weird to accept upper-case EXEC-FIL then... isn't it?
> >>
> >> (gdb) exec-fil
> >> No executable file now.
> >> (gdb) EXEC-FIL
> >> No executable file now.
> > 
> > I agree that if GDB accepts commands in upper case, the ambiguous
> > command message should work accordingly.
> 
> Agreed.  I thought that the manual mentioned that gdb accepts
> commands in either case, but I can't find it now.
> 

I don't find gdb accepts commands in either case in the manual, and
I am surprised that gdb does so.  Actually, gdb does so since 1988!

commit 7b4ac7e1ed2c4616bce56d1760807798be87ac9e
Author: gdb-2.4+.aux.coff <gdb@fsf.org>
Date:   Sat Jan 16 04:39:57 1988 +0000

    gdb-2.4+.aux.coff

in lookup_cmd function,

+  /* Find end of command name.  */
+
+  p = *line;
+  while (*p == '-'
+        || (*p >= 'a' && *p <= 'z')
+        || (*p >= 'A' && *p <= 'Z')
+        || (*p >= '1' && *p <= '9'))
+    {
+      if (*p >= 'A' && *p <= 'Z')
+       *p += 'a' - 'A';
+      p++;
+    }

however, I don't see any reason to do so.  At least, we need to be
clear that whether gdb accepts upper case commands or not.

-- 
Yao (齐尧)

Re: [RFA] candidates for ambiguous command in upper case

[Luis Machado]

On 01/11/2017 11:25 AM, Yao Qi wrote:
> On 17-01-10 17:00:28, Pedro Alves wrote:
>> On 01/10/2017 03:28 PM, Simon Marchi wrote:
>>> On 2017-01-10 10:19, Jerome Guitton wrote:
>>>> Yao Qi (qiyaoltc@gmail.com):
>>>>
>>>>> IMO, there is nothing wrong.  There is no command starts from "EX".
>>>>
>>>> This is a bit weird to accept upper-case EXEC-FIL then... isn't it?
>>>>
>>>> (gdb) exec-fil
>>>> No executable file now.
>>>> (gdb) EXEC-FIL
>>>> No executable file now.
>>>
>>> I agree that if GDB accepts commands in upper case, the ambiguous
>>> command message should work accordingly.
>>
>> Agreed.  I thought that the manual mentioned that gdb accepts
>> commands in either case, but I can't find it now.
>>
>
> I don't find gdb accepts commands in either case in the manual, and
> I am surprised that gdb does so.  Actually, gdb does so since 1988!
>
> commit 7b4ac7e1ed2c4616bce56d1760807798be87ac9e
> Author: gdb-2.4+.aux.coff <gdb@fsf.org>
> Date:   Sat Jan 16 04:39:57 1988 +0000
>
>     gdb-2.4+.aux.coff
>
> in lookup_cmd function,
>
> +  /* Find end of command name.  */
> +
> +  p = *line;
> +  while (*p == '-'
> +        || (*p >= 'a' && *p <= 'z')
> +        || (*p >= 'A' && *p <= 'Z')
> +        || (*p >= '1' && *p <= '9'))
> +    {
> +      if (*p >= 'A' && *p <= 'Z')
> +       *p += 'a' - 'A';
> +      p++;
> +    }
>
> however, I don't see any reason to do so.  At least, we need to be
> clear that whether gdb accepts upper case commands or not.
>

I think it makes for a more coherent command-handling environment. So 
load would be the same as LOAD, Load, LoAd, lOaD.

I can't think of a scenario where differentiating uppercase/lowercase 
commands in GDB's CLI would make a difference. Though i've noticed that 
MI commands are case-sensitive, which is incoherent. We ought to fix 
that too.

Re: [RFA] candidates for ambiguous command in upper case

[Pedro Alves]

On 01/11/2017 05:25 PM, Yao Qi wrote:
> On 17-01-10 17:00:28, Pedro Alves wrote:
>> On 01/10/2017 03:28 PM, Simon Marchi wrote:
>>> On 2017-01-10 10:19, Jerome Guitton wrote:
>>>> Yao Qi (qiyaoltc@gmail.com):
>>>>
>>>>> IMO, there is nothing wrong.  There is no command starts from "EX".
>>>>
>>>> This is a bit weird to accept upper-case EXEC-FIL then... isn't it?
>>>>
>>>> (gdb) exec-fil
>>>> No executable file now.
>>>> (gdb) EXEC-FIL
>>>> No executable file now.
>>>
>>> I agree that if GDB accepts commands in upper case, the ambiguous
>>> command message should work accordingly.
>>
>> Agreed.  I thought that the manual mentioned that gdb accepts
>> commands in either case, but I can't find it now.
>>
> 
> I don't find gdb accepts commands in either case in the manual, and
> I am surprised that gdb does so.  Actually, gdb does so since 1988!

I guess I probably discovered it by typing some command with
Caps Lock on by accident, and seeing it work.

I can only guess on original motivation -- maybe to make GDB usable
with uppercase-only terminals?  Those were common at some point in
the past.  I think Linux's terminal subsystem might still have
support for those.   But then symbol searching was not case-insensitive,
("set case-sensitive off" support was only added much later), so I
can't quite imagine how that'd be much usable.

Thanks,
Pedro Alves

Re: [RFA] candidates for ambiguous command in upper case

[Jerome Guitton]

Pedro Alves (palves@redhat.com):

> I can only guess on original motivation -- maybe to make GDB usable
> with uppercase-only terminals?  Those were common at some point in
> the past.  I think Linux's terminal subsystem might still have
> support for those.   But then symbol searching was not case-insensitive,
> ("set case-sensitive off" support was only added much later), so I
> can't quite imagine how that'd be much usable.

I'm not sure of the original motivation; but I guess that if it has
been there for thirty years it is now considered as the standard
interface by a few users.

In any case, even if we decide to change that, consistency would be
good, at least for CLI; the same policy for casing should apply in all
cases of completion.

Documenting it in the user manual would be good indeed; I'm not sure
where the proper place would be though.

Re: [RFA] candidates for ambiguous command in upper case

[Pedro Alves]

On 01/12/2017 10:18 AM, Jerome Guitton wrote:
> Pedro Alves (palves@redhat.com):
> 
>> I can only guess on original motivation -- maybe to make GDB usable
>> with uppercase-only terminals?  Those were common at some point in
>> the past.  I think Linux's terminal subsystem might still have
>> support for those.   But then symbol searching was not case-insensitive,
>> ("set case-sensitive off" support was only added much later), so I
>> can't quite imagine how that'd be much usable.
> 
> I'm not sure of the original motivation; but I guess that if it has
> been there for thirty years it is now considered as the standard
> interface by a few users.

Dunno, if it doesn't make sense, and nobody uses it, then it's one
less thing to maintain and test.  We don't treat command options
as case insensitive.  E.g.:

 (gdb) watch -locaTION *main
 No symbol "locaTION" in current context.

 (gdb) p /x obj
 $1 = 0x4007a0
 (gdb) p /X obj
 No symbol "X" in current context.

Etc.

If we removed support for case insensitive commands, then it may
open up interesting uses.

> In any case, even if we decide to change that, consistency would be
> good, at least for CLI; the same policy for casing should apply in all
> cases of completion.
> 
> Documenting it in the user manual would be good indeed; I'm not sure
> where the proper place would be though.

The place where I had expected to find it was where we talk about
unambiguous command abbreviations.  I.e., the very first thing
the manual talks about, once GDB is up and running:

 https://sourceware.org/gdb/current/onlinedocs/gdb/Commands.html#Commands

Thanks,
Pedro Alves

Re: [RFA] candidates for ambiguous command in upper case

[Jerome Guitton]

Pedro Alves (palves@redhat.com):

> Dunno, if it doesn't make sense, and nobody uses it, then it's one
> less thing to maintain and test.

Hard to figure out if someone uses it, I guess. This originally got
reported by one of our users as a minor inconsistancy, who also said
that he would be OK if gdb commands were case sensitive.

The patch that I'm suggesting is fairly simple, but my feeling is that
it would be just as easy to remove the feature.

I've tested the opposite: making the match case sensitive is a matter
of removing 4 characters in cli-decode.c. Not much consequences in the
testsuite. "handle sigq" still completes to "handle SIGQUIT".

So, what do we want to do?
1. Remove the feature?
2. Improve its consistency?
3. Keep things as is?

Re: [RFA] candidates for ambiguous command in upper case

[Pedro Alves]

On 01/16/2017 04:32 PM, Jerome Guitton wrote:
> Pedro Alves (palves@redhat.com):
> 
>> Dunno, if it doesn't make sense, and nobody uses it, then it's one
>> less thing to maintain and test.
> 
> Hard to figure out if someone uses it, I guess. This originally got
> reported by one of our users as a minor inconsistancy, who also said
> that he would be OK if gdb commands were case sensitive.
> 
> The patch that I'm suggesting is fairly simple, but my feeling is that
> it would be just as easy to remove the feature.
> 
> I've tested the opposite: making the match case sensitive is a matter
> of removing 4 characters in cli-decode.c. Not much consequences in the
> testsuite. "handle sigq" still completes to "handle SIGQUIT".
> 
> So, what do we want to do?
> 1. Remove the feature?
> 2. Improve its consistency?
> 3. Keep things as is?
> 

I vote #1.

Thanks,
Pedro Alves

Re: [RFA] candidates for ambiguous command in upper case

[Luis Machado]

On 01/16/2017 07:58 PM, Pedro Alves wrote:
> On 01/16/2017 04:32 PM, Jerome Guitton wrote:
>> Pedro Alves (palves@redhat.com):
>>
>>> Dunno, if it doesn't make sense, and nobody uses it, then it's one
>>> less thing to maintain and test.
>>
>> Hard to figure out if someone uses it, I guess. This originally got
>> reported by one of our users as a minor inconsistancy, who also said
>> that he would be OK if gdb commands were case sensitive.
>>
>> The patch that I'm suggesting is fairly simple, but my feeling is that
>> it would be just as easy to remove the feature.
>>
>> I've tested the opposite: making the match case sensitive is a matter
>> of removing 4 characters in cli-decode.c. Not much consequences in the
>> testsuite. "handle sigq" still completes to "handle SIGQUIT".
>>
>> So, what do we want to do?
>> 1. Remove the feature?
>> 2. Improve its consistency?
>> 3. Keep things as is?
>>
>
> I vote #1.

I don't see a problem with #1 as long as we keep it consistent 
throughout from now on.

Re: [RFA] candidates for ambiguous command in upper case

[Pedro Alves]

On 01/17/2017 04:29 PM, Luis Machado wrote:
> 
> I don't see a problem with #1 as long as we keep it consistent
> throughout from now on.

Can you expand on exactly what you mean by the "as long" part?

Thanks,
Pedro Alves

Re: [RFA] candidates for ambiguous command in upper case

[Luis Machado]

On 01/17/2017 10:34 AM, Pedro Alves wrote:
> On 01/17/2017 04:29 PM, Luis Machado wrote:
>>
>> I don't see a problem with #1 as long as we keep it consistent
>> throughout from now on.
>
> Can you expand on exactly what you mean by the "as long" part?
>
> Thanks,
> Pedro Alves
>
>

Meaning that, if we go with #1, we should make sure we are not doing 
case-insensitive comparisons in gdb unless it is clearly stated we 
should do it (like handling of Windows paths i suppose).

For the record, i think #3 is not acceptable and we don't seem to have a 
good justification for keeping the behavior of #2 other than "we've been 
doing this since ...".

So i think #1 would be the best. I just wanted to point out we may want 
to make sure there are no other gdb places with the same undocumented 
behavior.

Does that make sense?

Re: [RFA] candidates for ambiguous command in upper case

[Pedro Alves]

On 01/17/2017 04:51 PM, Luis Machado wrote:
> On 01/17/2017 10:34 AM, Pedro Alves wrote:
>> On 01/17/2017 04:29 PM, Luis Machado wrote:
>>>
>>> I don't see a problem with #1 as long as we keep it consistent
>>> throughout from now on.
>>
>> Can you expand on exactly what you mean by the "as long" part?

> Meaning that, if we go with #1, we should make sure we are not doing
> case-insensitive comparisons in gdb unless it is clearly stated we
> should do it (like handling of Windows paths i suppose).

Would you say that we should stop completing "handle sig" to "handle SIG"?
"handle" doesn't accept lowercase signal names, but it could be
argued that the completer is helping the user here.

Grepping for strncasecmp doesn't find all that many hits, and several
are in symbol lookup or path handling stuff where they're probably rightly
used.  

The ones in tracepoint.c do look like of the inconsistent-user-interface sort.
I had never realized we accept $REG etc. in tracepoint actions.

Thanks,
Pedro Alves

Re: [RFA] candidates for ambiguous command in upper case

[Luis Machado]

On 01/17/2017 11:04 AM, Pedro Alves wrote:
> On 01/17/2017 04:51 PM, Luis Machado wrote:
>> On 01/17/2017 10:34 AM, Pedro Alves wrote:
>>> On 01/17/2017 04:29 PM, Luis Machado wrote:
>>>>
>>>> I don't see a problem with #1 as long as we keep it consistent
>>>> throughout from now on.
>>>
>>> Can you expand on exactly what you mean by the "as long" part?
>
>> Meaning that, if we go with #1, we should make sure we are not doing
>> case-insensitive comparisons in gdb unless it is clearly stated we
>> should do it (like handling of Windows paths i suppose).
>
> Would you say that we should stop completing "handle sig" to "handle SIG"?
> "handle" doesn't accept lowercase signal names, but it could be
> argued that the completer is helping the user here.
>

That sounds like a one-off case where it is useful.

> Grepping for strncasecmp doesn't find all that many hits, and several
> are in symbol lookup or path handling stuff where they're probably rightly
> used.
>

I'll go through the code to see if there are any other occurrences.

> The ones in tracepoint.c do look like of the inconsistent-user-interface sort.
> I had never realized we accept $REG etc. in tracepoint actions.
>

Neither did i. This one looks like it could be dropped.

Re: [RFA] candidates for ambiguous command in upper case

[Jerome Guitton]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

Luis Machado (lgustavo@codesourcery.com):

> >>So, what do we want to do?
> >>1. Remove the feature?
> >>2. Improve its consistency?
> >>3. Keep things as is?
> >>
> >
> >I vote #1.
> 
> I don't see a problem with #1 as long as we keep it consistent
> throughout from now on.

OK, I'm happy with #1 as well! New patch in attachment. OK to apply?

Thanks,
Jerome

[-- Attachment #2: 2017-01-31-case-sensitive-command.diff --]
[-- Type: text/x-diff, Size: 1825 bytes --]

commit d73d94c6d55e8cca5a38551207f65dfa2e47d054
Author: Jerome Guitton <guitton@adacore.com>
Date:   Fri Jan 27 17:06:32 2017 +0100

    Command names: make them case sensitive
    
    Case-insensitive search for command names is an obscure undocumented
    feature, which seems to be unused, is not tested and not quite
    consistent. Remove it.
    
    gdb/ChangeLog:
    
    	* cli-decode.c (lookup_cmd_1, lookup_cmd_composition):
    	Remove case-insensitive search.

diff --git a/gdb/cli/cli-decode.c b/gdb/cli/cli-decode.c
index 436a7ed..155d6d1 100644
--- a/gdb/cli/cli-decode.c
+++ b/gdb/cli/cli-decode.c
@@ -1378,19 +1378,6 @@ lookup_cmd_1 (const char **text, struct cmd_list_element *clist,
   nfound = 0;
   found = find_cmd (command, len, clist, ignore_help_classes, &nfound);
 
-  /* We didn't find the command in the entered case, so lower case it
-     and search again.  */
-  if (!found || nfound == 0)
-    {
-      for (tmp = 0; tmp < len; tmp++)
-	{
-	  char x = command[tmp];
-
-	  command[tmp] = isupper (x) ? tolower (x) : x;
-	}
-      found = find_cmd (command, len, clist, ignore_help_classes, &nfound);
-    }
-
   /* If nothing matches, we have a simple failure.  */
   if (nfound == 0)
     return 0;
@@ -1731,20 +1718,6 @@ lookup_cmd_composition (const char *text,
       nfound = 0;
       *cmd = find_cmd (command, len, cur_list, 1, &nfound);
       
-      /* We didn't find the command in the entered case, so lower case
-	 it and search again.
-      */
-      if (!*cmd || nfound == 0)
-	{
-	  for (tmp = 0; tmp < len; tmp++)
-	    {
-	      char x = command[tmp];
-
-	      command[tmp] = isupper (x) ? tolower (x) : x;
-	    }
-	  *cmd = find_cmd (command, len, cur_list, 1, &nfound);
-	}
-      
       if (*cmd == CMD_LIST_AMBIGUOUS)
 	{
 	  return 0;              /* ambiguous */

Re: [RFA] candidates for ambiguous command in upper case

[Pedro Alves]

On 01/31/2017 02:39 PM, Jerome Guitton wrote:
> Luis Machado (lgustavo@codesourcery.com):
> 
>>>> So, what do we want to do?
>>>> 1. Remove the feature?
>>>> 2. Improve its consistency?
>>>> 3. Keep things as is?
>>>>
>>>
>>> I vote #1.
>>
>> I don't see a problem with #1 as long as we keep it consistent
>> throughout from now on.
> 
> OK, I'm happy with #1 as well! New patch in attachment. OK to apply?

LGTM.

Thanks,
Pedro Alves

Re: [RFA] candidates for ambiguous command in upper case

[Jerome Guitton]

Pedro Alves (palves@redhat.com):

> LGTM.

This one has been committed as well.

Thanks again,
Jerome

Re: [RFA] candidates for ambiguous command in upper case

[Simon Marchi]

On 2017-02-08 07:05 PM, Jerome Guitton wrote:
> Pedro Alves (palves@redhat.com):
> 
>> LGTM.
> 
> This one has been committed as well.
> 
> Thanks again,
> Jerome
> 

Hi all,

This patch indirectly causes a regression with user-defined commands that include
capital letters.

define_command converts the command name to lower case, assuming that the command
lookup mechanism is case insensitive:

  /* If the rest of the commands will be case insensitive, this one
     should behave in the same manner.  */
  for (tem = comname; *tem; tem++)
    if (isupper (*tem))
      *tem = tolower (*tem);

Therefore, ff a user defines command Foo, it will be transformed to foo, and only
accessible by typing "foo".  Since the command system is now case sensitive, I think
we should remove that conversion.  The command Foo will then only be accessible with
"Foo", not "foo" nor "FOO".

Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=21827

WDYT?

Simon

[PATCH] define_command: Don't convert command name to lower case

[Simon Marchi]

I think this won't be too controversial, so I went ahead and made a patch for
it.

Commit

  Command names: make them case sensitive
  3d7b173c29900879c9a5958dd6029fd36666e57c

made command name lookup case sensitive.  However, define_command, used
when creating a user-defined command, converts the command name to
lowercase, assuming that the command name lookup works in a case
insensitive way.  This causes user-defined commands with capital letters
in their name to only be callable with a lowercase version:

  (gdb) define Foo
  Type commands for definition of "Foo".
  End with a line saying just "end".
  >print 1
  >end
  (gdb) Foo
  Undefined command: "Foo".  Try "help".
  (gdb) foo
  $1 = 1

This patch removes that conversion to lowercase, so that the user can
call the command with the same name they provided.

gdb/ChangeLog:

	* cli/cli-script.c (define_command): Don't convert command name
	to lower case.

gdb/testsuite/ChangeLog:

	* gdb.base/commands.exp (user_defined_command_case_sensitivity):
	New proc, call it from toplevel.
---
 gdb/cli/cli-script.c                |  6 ------
 gdb/testsuite/gdb.base/commands.exp | 20 ++++++++++++++++++++
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
index 5674404..481cc01 100644
--- a/gdb/cli/cli-script.c
+++ b/gdb/cli/cli-script.c
@@ -1499,12 +1499,6 @@ define_command (char *comname, int from_tty)
 
   comname = xstrdup (comname);
 
-  /* If the rest of the commands will be case insensitive, this one
-     should behave in the same manner.  */
-  for (tem = comname; *tem; tem++)
-    if (isupper (*tem))
-      *tem = tolower (*tem);
-
   xsnprintf (tmpbuf, sizeof (tmpbuf),
 	     "Type commands for definition of \"%s\".", comfull);
   command_line_up cmds = read_command_lines (tmpbuf, from_tty, 1, 0, 0);
diff --git a/gdb/testsuite/gdb.base/commands.exp b/gdb/testsuite/gdb.base/commands.exp
index 4963743..3ccd8b1 100644
--- a/gdb/testsuite/gdb.base/commands.exp
+++ b/gdb/testsuite/gdb.base/commands.exp
@@ -352,6 +352,25 @@ proc_with_prefix user_defined_command_test {} {
 	"display user-defined empty command"
 }
 
+# Test that the case with which the command was defined is preserved.
+
+proc_with_prefix user_defined_command_case_sensitivity {} {
+    global gdb_prompt
+
+    set test "define Homer-Simpson"
+    gdb_test_multiple $test $test {
+	    -re "End with"  {
+		pass $test
+	    }
+	}
+
+    gdb_test "print 123\nend" "" "enter commands"
+
+    gdb_test "Homer-Simpson" " = 123" "execute command"
+    gdb_test "HOMER-SIMPSON" "Undefined command.*" "try to call in upper case"
+    gdb_test "homer-simpson" "Undefined command.*" "try to call in lower case"
+}
+
 # Test that "eval" in a user-defined command expands $argc/$argN.
 
 proc_with_prefix user_defined_command_args_eval {} {
@@ -1052,6 +1071,7 @@ if_while_breakpoint_command_test
 infrun_breakpoint_command_test
 breakpoint_command_test
 user_defined_command_test
+user_defined_command_case_sensitivity
 user_defined_command_args_eval
 user_defined_command_args_stack_test
 user_defined_command_manyargs_test
-- 
2.7.4

Re: [PATCH] define_command: Don't convert command name to lower case

[Simon Marchi]

On 2017-07-24 11:47 PM, Simon Marchi wrote:
> I think this won't be too controversial, so I went ahead and made a patch for
> it.
> 
> Commit
> 
>   Command names: make them case sensitive
>   3d7b173c29900879c9a5958dd6029fd36666e57c
> 
> made command name lookup case sensitive.  However, define_command, used
> when creating a user-defined command, converts the command name to
> lowercase, assuming that the command name lookup works in a case
> insensitive way.  This causes user-defined commands with capital letters
> in their name to only be callable with a lowercase version:
> 
>   (gdb) define Foo
>   Type commands for definition of "Foo".
>   End with a line saying just "end".
>   >print 1
>   >end
>   (gdb) Foo
>   Undefined command: "Foo".  Try "help".
>   (gdb) foo
>   $1 = 1
> 
> This patch removes that conversion to lowercase, so that the user can
> call the command with the same name they provided.

I forgot to mention but this would be a candidate for the 8.0 branch as well,
since it's a regression.

Simon

Re: [PATCH] define_command: Don't convert command name to lower case

[Simon Marchi]

On 2017-07-24 11:54 PM, Simon Marchi wrote:
> On 2017-07-24 11:47 PM, Simon Marchi wrote:
>> I think this won't be too controversial, so I went ahead and made a patch for
>> it.
>>
>> Commit
>>
>>   Command names: make them case sensitive
>>   3d7b173c29900879c9a5958dd6029fd36666e57c
>>
>> made command name lookup case sensitive.  However, define_command, used
>> when creating a user-defined command, converts the command name to
>> lowercase, assuming that the command name lookup works in a case
>> insensitive way.  This causes user-defined commands with capital letters
>> in their name to only be callable with a lowercase version:
>>
>>   (gdb) define Foo
>>   Type commands for definition of "Foo".
>>   End with a line saying just "end".
>>   >print 1
>>   >end
>>   (gdb) Foo
>>   Undefined command: "Foo".  Try "help".
>>   (gdb) foo
>>   $1 = 1
>>
>> This patch removes that conversion to lowercase, so that the user can
>> call the command with the same name they provided.
> 
> I forgot to mention but this would be a candidate for the 8.0 branch as well,
> since it's a regression.
> 
> Simon
> 

This is now pushed to master and gdb-8.0-branch.  I made a small change to the test,
in order to test that multiple commands whose names differ only by case don't
interfere.


From fd437cbc432d5421492a5b0e371750de104cce93 Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@ericsson.com>
Date: Mon, 28 Aug 2017 23:05:04 +0200
Subject: [PATCH] define_command: Don't convert command name to lower case

Commit

  Command names: make them case sensitive
  3d7b173c29900879c9a5958dd6029fd36666e57c

made command name lookup case sensitive.  However, define_command, used
when creating a user-defined command, converts the command name to
lowercase, assuming that the command name lookup works in a case
insensitive way.  This causes user-defined commands with capital letters
in their name to only be callable with a lowercase version:

  (gdb) define Foo
  Type commands for definition of "Foo".
  End with a line saying just "end".
  >print 1
  >end
  (gdb) Foo
  Undefined command: "Foo".  Try "help".
  (gdb) foo
  $1 = 1

This patch removes that conversion to lowercase, so that the user can
call the command with the same name they provided.

gdb/ChangeLog:

	* cli/cli-script.c (define_command): Don't convert command name
	to lower case.

gdb/testsuite/ChangeLog:

	* gdb.base/commands.exp (user_defined_command_case_sensitivity):
	New proc, call it from toplevel.
---
 gdb/ChangeLog                       |  5 +++++
 gdb/cli/cli-script.c                |  6 ------
 gdb/testsuite/ChangeLog             |  5 +++++
 gdb/testsuite/gdb.base/commands.exp | 30 ++++++++++++++++++++++++++++++
 4 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 39ff4ed..73106bf 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2017-08-28  Simon Marchi  <simon.marchi@ericsson.com>
+
+	* cli/cli-script.c (define_command): Don't convert command name
+	to lower case.
+
 2017-08-25  Joel Brobecker  <brobecker@adacore.com>

 	* ada-lang.c (ada_lookup_struct_elt_type): Remove parameter "dispp".
diff --git a/gdb/cli/cli-script.c b/gdb/cli/cli-script.c
index 4b8ae0b..64b4c2b 100644
--- a/gdb/cli/cli-script.c
+++ b/gdb/cli/cli-script.c
@@ -1478,12 +1478,6 @@ define_command (char *comname, int from_tty)

   comname = xstrdup (comname);

-  /* If the rest of the commands will be case insensitive, this one
-     should behave in the same manner.  */
-  for (tem = comname; *tem; tem++)
-    if (isupper (*tem))
-      *tem = tolower (*tem);
-
   xsnprintf (tmpbuf, sizeof (tmpbuf),
 	     "Type commands for definition of \"%s\".", comfull);
   command_line_up cmds = read_command_lines (tmpbuf, from_tty, 1, 0, 0);
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 56ff191..83261df 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2017-08-28  Simon Marchi  <simon.marchi@ericsson.com>
+
+	* gdb.base/commands.exp (user_defined_command_case_sensitivity):
+	New proc, call it from toplevel.
+
 2017-08-23  Sergio Durigan Junior  <sergiodj@redhat.com>

 	PR remote/21852
diff --git a/gdb/testsuite/gdb.base/commands.exp b/gdb/testsuite/gdb.base/commands.exp
index 4963743..4cd5f46 100644
--- a/gdb/testsuite/gdb.base/commands.exp
+++ b/gdb/testsuite/gdb.base/commands.exp
@@ -352,6 +352,35 @@ proc_with_prefix user_defined_command_test {} {
 	"display user-defined empty command"
 }

+# Test that the case with which the command was defined is preserved.
+
+proc_with_prefix user_defined_command_case_sensitivity {} {
+    # Define a first command with mixed case name.
+    set test "define Homer-Simpson"
+    gdb_test_multiple $test $test {
+	    -re "End with"  {
+		pass $test
+	    }
+	}
+
+    gdb_test "print 123\nend" "" "enter commands 1"
+
+    # Define a second command, same name but different case.
+    set test "define HomeR-SimpsoN"
+    gdb_test_multiple $test $test {
+	    -re "End with"  {
+		pass $test
+	    }
+	}
+
+    gdb_test "print 456\nend" "" "enter commands 2"
+
+    gdb_test "Homer-Simpson" " = 123" "execute command"
+    gdb_test "HomeR-SimpsoN" " = 456" "execute command"
+    gdb_test "HOMER-SIMPSON" "Undefined command.*" "try to call in upper case"
+    gdb_test "homer-simpson" "Undefined command.*" "try to call in lower case"
+}
+
 # Test that "eval" in a user-defined command expands $argc/$argN.

 proc_with_prefix user_defined_command_args_eval {} {
@@ -1052,6 +1081,7 @@ if_while_breakpoint_command_test
 infrun_breakpoint_command_test
 breakpoint_command_test
 user_defined_command_test
+user_defined_command_case_sensitivity
 user_defined_command_args_eval
 user_defined_command_args_stack_test
 user_defined_command_manyargs_test
-- 
2.7.4

Re: [PATCH] define_command: Don't convert command name to lower case

[Jerome Guitton]

Simon Marchi (simon.marchi@ericsson.com):

> I think this won't be too controversial, so I went ahead and made a patch for
> it.

Thanks for catching this and fixing it!