* [RFA] candidates for ambiguous command in upper case @ 2017-01-10 14:25 Jerome Guitton 2017-01-10 15:07 ` Yao Qi 0 siblings, 1 reply; 27+ messages in thread From: Jerome Guitton @ 2017-01-10 14:25 UTC (permalink / raw) To: gdb-patches; +Cc: Jerome Guitton 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": . 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 ambigous command. gdb/testsuite/ChangeLog: * gdb.base/completion.exp: Add test for ambiguous upper case command. --- gdb/cli/cli-decode.c | 2 +- gdb/testsuite/gdb.base/completion.exp | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/gdb/cli/cli-decode.c b/gdb/cli/cli-decode.c index d3be93c..d59fe9b 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) diff --git a/gdb/testsuite/gdb.base/completion.exp b/gdb/testsuite/gdb.base/completion.exp index 4a3ee4b..9a7a221 100644 --- a/gdb/testsuite/gdb.base/completion.exp +++ b/gdb/testsuite/gdb.base/completion.exp @@ -265,6 +265,19 @@ 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 t '" send_gdb "info t \t" gdb_test_multiple "" "$test" { -- 1.7.10.4 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-10 14:25 [RFA] candidates for ambiguous command in upper case Jerome Guitton @ 2017-01-10 15:07 ` Yao Qi 2017-01-10 15:19 ` Jerome Guitton 0 siblings, 1 reply; 27+ messages in thread From: Yao Qi @ 2017-01-10 15:07 UTC (permalink / raw) To: Jerome Guitton; +Cc: gdb-patches 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 (é½å°§) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-10 15:07 ` Yao Qi @ 2017-01-10 15:19 ` Jerome Guitton 2017-01-10 15:28 ` Simon Marchi 0 siblings, 1 reply; 27+ messages in thread From: Jerome Guitton @ 2017-01-10 15:19 UTC (permalink / raw) To: Yao Qi; +Cc: gdb-patches 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-10 15:19 ` Jerome Guitton @ 2017-01-10 15:28 ` Simon Marchi 2017-01-10 15:40 ` Jerome Guitton 2017-01-10 17:00 ` Pedro Alves 0 siblings, 2 replies; 27+ messages in thread From: Simon Marchi @ 2017-01-10 15:28 UTC (permalink / raw) To: Jerome Guitton; +Cc: Yao Qi, gdb-patches 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"? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-10 15:28 ` Simon Marchi @ 2017-01-10 15:40 ` Jerome Guitton 2017-01-10 17:00 ` Pedro Alves 1 sibling, 0 replies; 27+ messages in thread From: Jerome Guitton @ 2017-01-10 15:40 UTC (permalink / raw) To: Simon Marchi; +Cc: Yao Qi, gdb-patches 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-10 15:28 ` Simon Marchi 2017-01-10 15:40 ` Jerome Guitton @ 2017-01-10 17:00 ` Pedro Alves 2017-01-11 15:37 ` Jerome Guitton 2017-01-11 17:26 ` Yao Qi 1 sibling, 2 replies; 27+ messages in thread From: Pedro Alves @ 2017-01-10 17:00 UTC (permalink / raw) To: Simon Marchi, Jerome Guitton; +Cc: Yao Qi, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-10 17:00 ` Pedro Alves @ 2017-01-11 15:37 ` Jerome Guitton 2017-01-11 17:26 ` Yao Qi 1 sibling, 0 replies; 27+ messages in thread From: Jerome Guitton @ 2017-01-11 15:37 UTC (permalink / raw) To: Pedro Alves; +Cc: Simon Marchi, Yao Qi, gdb-patches [-- 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" { ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-10 17:00 ` Pedro Alves 2017-01-11 15:37 ` Jerome Guitton @ 2017-01-11 17:26 ` Yao Qi 2017-01-11 17:35 ` Luis Machado 2017-01-11 20:24 ` Pedro Alves 1 sibling, 2 replies; 27+ messages in thread From: Yao Qi @ 2017-01-11 17:26 UTC (permalink / raw) To: Pedro Alves; +Cc: Simon Marchi, Jerome Guitton, gdb-patches 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 (é½å°§) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-11 17:26 ` Yao Qi @ 2017-01-11 17:35 ` Luis Machado 2017-01-11 20:24 ` Pedro Alves 1 sibling, 0 replies; 27+ messages in thread From: Luis Machado @ 2017-01-11 17:35 UTC (permalink / raw) To: Yao Qi, Pedro Alves; +Cc: Simon Marchi, Jerome Guitton, gdb-patches 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-11 17:26 ` Yao Qi 2017-01-11 17:35 ` Luis Machado @ 2017-01-11 20:24 ` Pedro Alves 2017-01-12 10:18 ` Jerome Guitton 1 sibling, 1 reply; 27+ messages in thread From: Pedro Alves @ 2017-01-11 20:24 UTC (permalink / raw) To: Yao Qi; +Cc: Simon Marchi, Jerome Guitton, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-11 20:24 ` Pedro Alves @ 2017-01-12 10:18 ` Jerome Guitton 2017-01-12 16:37 ` Pedro Alves 0 siblings, 1 reply; 27+ messages in thread From: Jerome Guitton @ 2017-01-12 10:18 UTC (permalink / raw) To: Pedro Alves; +Cc: Yao Qi, Simon Marchi, gdb-patches 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-12 10:18 ` Jerome Guitton @ 2017-01-12 16:37 ` Pedro Alves 2017-01-16 16:32 ` Jerome Guitton 0 siblings, 1 reply; 27+ messages in thread From: Pedro Alves @ 2017-01-12 16:37 UTC (permalink / raw) To: Jerome Guitton; +Cc: Yao Qi, Simon Marchi, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-12 16:37 ` Pedro Alves @ 2017-01-16 16:32 ` Jerome Guitton 2017-01-17 1:58 ` Pedro Alves 0 siblings, 1 reply; 27+ messages in thread From: Jerome Guitton @ 2017-01-16 16:32 UTC (permalink / raw) To: Pedro Alves; +Cc: Yao Qi, Simon Marchi, gdb-patches 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-16 16:32 ` Jerome Guitton @ 2017-01-17 1:58 ` Pedro Alves 2017-01-17 16:29 ` Luis Machado 0 siblings, 1 reply; 27+ messages in thread From: Pedro Alves @ 2017-01-17 1:58 UTC (permalink / raw) To: Jerome Guitton; +Cc: Yao Qi, Simon Marchi, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-17 1:58 ` Pedro Alves @ 2017-01-17 16:29 ` Luis Machado 2017-01-17 16:35 ` Pedro Alves 2017-01-31 14:39 ` Jerome Guitton 0 siblings, 2 replies; 27+ messages in thread From: Luis Machado @ 2017-01-17 16:29 UTC (permalink / raw) To: Pedro Alves, Jerome Guitton; +Cc: Yao Qi, Simon Marchi, gdb-patches 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-17 16:29 ` Luis Machado @ 2017-01-17 16:35 ` Pedro Alves 2017-01-17 16:51 ` Luis Machado 2017-01-31 14:39 ` Jerome Guitton 1 sibling, 1 reply; 27+ messages in thread From: Pedro Alves @ 2017-01-17 16:35 UTC (permalink / raw) To: Luis Machado, Jerome Guitton; +Cc: Yao Qi, Simon Marchi, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-17 16:35 ` Pedro Alves @ 2017-01-17 16:51 ` Luis Machado 2017-01-17 17:04 ` Pedro Alves 0 siblings, 1 reply; 27+ messages in thread From: Luis Machado @ 2017-01-17 16:51 UTC (permalink / raw) To: Pedro Alves, Jerome Guitton; +Cc: Yao Qi, Simon Marchi, gdb-patches 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? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-17 16:51 ` Luis Machado @ 2017-01-17 17:04 ` Pedro Alves 2017-01-17 17:13 ` Luis Machado 0 siblings, 1 reply; 27+ messages in thread From: Pedro Alves @ 2017-01-17 17:04 UTC (permalink / raw) To: Luis Machado, Jerome Guitton; +Cc: Yao Qi, Simon Marchi, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-17 17:04 ` Pedro Alves @ 2017-01-17 17:13 ` Luis Machado 0 siblings, 0 replies; 27+ messages in thread From: Luis Machado @ 2017-01-17 17:13 UTC (permalink / raw) To: Pedro Alves, Jerome Guitton; +Cc: Yao Qi, Simon Marchi, gdb-patches 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-17 16:29 ` Luis Machado 2017-01-17 16:35 ` Pedro Alves @ 2017-01-31 14:39 ` Jerome Guitton 2017-01-31 15:20 ` Pedro Alves 1 sibling, 1 reply; 27+ messages in thread From: Jerome Guitton @ 2017-01-31 14:39 UTC (permalink / raw) To: Luis Machado; +Cc: Pedro Alves, Yao Qi, Simon Marchi, gdb-patches [-- 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 */ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-31 14:39 ` Jerome Guitton @ 2017-01-31 15:20 ` Pedro Alves 2017-02-08 18:05 ` Jerome Guitton 0 siblings, 1 reply; 27+ messages in thread From: Pedro Alves @ 2017-01-31 15:20 UTC (permalink / raw) To: Jerome Guitton, Luis Machado; +Cc: Yao Qi, Simon Marchi, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-01-31 15:20 ` Pedro Alves @ 2017-02-08 18:05 ` Jerome Guitton 2017-07-24 21:17 ` Simon Marchi 0 siblings, 1 reply; 27+ messages in thread From: Jerome Guitton @ 2017-02-08 18:05 UTC (permalink / raw) To: Pedro Alves; +Cc: Luis Machado, Yao Qi, Simon Marchi, gdb-patches Pedro Alves (palves@redhat.com): > LGTM. This one has been committed as well. Thanks again, Jerome ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [RFA] candidates for ambiguous command in upper case 2017-02-08 18:05 ` Jerome Guitton @ 2017-07-24 21:17 ` Simon Marchi 2017-07-24 21:48 ` [PATCH] define_command: Don't convert command name to lower case Simon Marchi 0 siblings, 1 reply; 27+ messages in thread From: Simon Marchi @ 2017-07-24 21:17 UTC (permalink / raw) To: Jerome Guitton, Pedro Alves Cc: Luis Machado, Yao Qi, Simon Marchi, gdb-patches 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] define_command: Don't convert command name to lower case 2017-07-24 21:17 ` Simon Marchi @ 2017-07-24 21:48 ` Simon Marchi 2017-07-24 21:54 ` Simon Marchi 2017-07-26 12:42 ` Jerome Guitton 0 siblings, 2 replies; 27+ messages in thread From: Simon Marchi @ 2017-07-24 21:48 UTC (permalink / raw) To: gdb-patches; +Cc: guitton, 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] define_command: Don't convert command name to lower case 2017-07-24 21:48 ` [PATCH] define_command: Don't convert command name to lower case Simon Marchi @ 2017-07-24 21:54 ` Simon Marchi 2017-08-28 21:20 ` Simon Marchi 2017-07-26 12:42 ` Jerome Guitton 1 sibling, 1 reply; 27+ messages in thread From: Simon Marchi @ 2017-07-24 21:54 UTC (permalink / raw) To: gdb-patches; +Cc: guitton 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] define_command: Don't convert command name to lower case 2017-07-24 21:54 ` Simon Marchi @ 2017-08-28 21:20 ` Simon Marchi 0 siblings, 0 replies; 27+ messages in thread From: Simon Marchi @ 2017-08-28 21:20 UTC (permalink / raw) To: gdb-patches; +Cc: guitton 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] define_command: Don't convert command name to lower case 2017-07-24 21:48 ` [PATCH] define_command: Don't convert command name to lower case Simon Marchi 2017-07-24 21:54 ` Simon Marchi @ 2017-07-26 12:42 ` Jerome Guitton 1 sibling, 0 replies; 27+ messages in thread From: Jerome Guitton @ 2017-07-26 12:42 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb-patches 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! ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2017-08-28 21:20 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-10 14:25 [RFA] candidates for ambiguous command in upper case Jerome Guitton 2017-01-10 15:07 ` Yao Qi 2017-01-10 15:19 ` Jerome Guitton 2017-01-10 15:28 ` Simon Marchi 2017-01-10 15:40 ` Jerome Guitton 2017-01-10 17:00 ` Pedro Alves 2017-01-11 15:37 ` Jerome Guitton 2017-01-11 17:26 ` Yao Qi 2017-01-11 17:35 ` Luis Machado 2017-01-11 20:24 ` Pedro Alves 2017-01-12 10:18 ` Jerome Guitton 2017-01-12 16:37 ` Pedro Alves 2017-01-16 16:32 ` Jerome Guitton 2017-01-17 1:58 ` Pedro Alves 2017-01-17 16:29 ` Luis Machado 2017-01-17 16:35 ` Pedro Alves 2017-01-17 16:51 ` Luis Machado 2017-01-17 17:04 ` Pedro Alves 2017-01-17 17:13 ` Luis Machado 2017-01-31 14:39 ` Jerome Guitton 2017-01-31 15:20 ` Pedro Alves 2017-02-08 18:05 ` Jerome Guitton 2017-07-24 21:17 ` Simon Marchi 2017-07-24 21:48 ` [PATCH] define_command: Don't convert command name to lower case Simon Marchi 2017-07-24 21:54 ` Simon Marchi 2017-08-28 21:20 ` Simon Marchi 2017-07-26 12:42 ` Jerome Guitton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).