This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb v7.0 - user defined command's document section - space prefixed end
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 18 Nov 2009 23:41:56 +0300
- Subject: Re: gdb v7.0 - user defined command's document section - space prefixed end
- References: <4AE7D19A.70600@googlemail.com> <hd1o0t$cl2$1@ger.gmane.org> <20091113143605.GA18096@caradoc.them.org>
On Friday 13 November 2009 17:36:05 Daniel Jacobowitz wrote:
> On Fri, Nov 06, 2009 at 08:56:40PM +0300, Vladimir Prus wrote:
> > Note that comment has disappeared, but it's not me -- process_next_line is given
> > an empty string, presumably because readline is trying to act smart.
>
> It's command_line_input, from top.c. It also does history expansion.
> Oh, well... for another day.
>
> This patch is OK. Please include changelogs...
>
> > + if (parse_commands)
> > + {
> > + /* If commands are parsed, we skip initial spaces. Otherwise,
> > + which is the case for Python commands and documentation
> > + (see the 'document' command), spaces are preserved. */
> > + p = p2;
> > + }
> >
> > if (parse_commands)
> > {
> >
>
> Want to combine the two if statements?
Yes, thanks. Here's the final version I've checked in.
- Volodya
Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.11088
diff -u -p -r1.11088 ChangeLog
--- gdb/ChangeLog 18 Nov 2009 16:28:42 -0000 1.11088
+++ gdb/ChangeLog 18 Nov 2009 20:40:56 -0000
@@ -1,3 +1,9 @@
+2009-11-18 Vladimir Prus <vladimir@codesourcery.com>
+
+ * cli/cli-script.c (process_next_line): Recognize 'end'
+ even when the line has leading space and we're not parsing
+ commands.
+
2009-11-18 Tom Tromey <tromey@redhat.com>
* symtab.c (symbol_set_names): Correctly set 'name' on symbol when
Index: gdb/cli/cli-script.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-script.c,v
retrieving revision 1.53
diff -u -p -r1.53 cli-script.c
--- gdb/cli/cli-script.c 3 Aug 2009 12:26:37 -0000 1.53
+++ gdb/cli/cli-script.c 18 Nov 2009 20:40:56 -0000
@@ -879,30 +879,35 @@ static enum misc_command_type
process_next_line (char *p, struct command_line **command, int parse_commands)
{
char *p1;
+ char *p2;
int not_handled = 0;
/* Not sure what to do here. */
if (p == NULL)
return end_command;
- if (parse_commands)
- {
- /* Strip leading whitespace. */
- while (*p == ' ' || *p == '\t')
- p++;
- }
-
/* Strip trailing whitespace. */
p1 = p + strlen (p);
while (p1 != p && (p1[-1] == ' ' || p1[-1] == '\t'))
p1--;
- /* Is this the end of a simple, while, or if control structure? */
- if (p1 - p == 3 && !strncmp (p, "end", 3))
+ p2 = p;
+ /* Strip leading whitespace. */
+ while (*p2 == ' ' || *p2 == '\t')
+ p2++;
+
+ /* 'end' is always recognized, regardless of parse_commands value.
+ We also permit whitespace before end and after. */
+ if (p1 - p2 == 3 && !strncmp (p2, "end", 3))
return end_command;
-
+
if (parse_commands)
{
+ /* If commands are parsed, we skip initial spaces. Otherwise,
+ which is the case for Python commands and documentation
+ (see the 'document' command), spaces are preserved. */
+ p = p2;
+
/* Blanks and comments don't really do anything, but we need to
distinguish them from else, end and other commands which can be
executed. */