This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Strangeness in set command
On Tue, 2008-04-08 at 11:57 +0100, Andrew STUBBS wrote:
> Eli Zaretskii wrote:
> >> From: Michael Snyder <msnyder@specifix.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, Andreas Schwab <schwab@suse.de>, gdb@sources.redhat.com
> >> Date: Mon, 07 Apr 2008 12:05:59 -0700
> >>
> >> The problem is that "so long as it is not ambiguous"
> >> is dicy, and changes over time as we add new subcommands
> >> to "set".
> >>
> >> The shortcut is probably one of those "seemed like a
> >> good idea at the time" things, but now it's established
> >> and we're stuck with it.
> >>
> >> It would probably be a good idea if, every time we parse
> >> a "set" command, we try to match it with BOTH a variable
> >> AND a subcommand, and if there is ambiguity we say so
> >> explicitly.
> >
> > Or maybe, if the text after "set " has a `=' character in it, we
> > should ask whether the user really meant "set variable". IOW, refuse
> > to obey this shortcut, even if it's unambiguous.
> >
>
> Hmmm, that's not great for set args:
>
> (gdb) set args --command=myscript
Well, ok, you could parse the first token (in this case "args"),
and then look for an = following it. But you could have expressions
where the assignment operator wouldn't be the first token, eg:
set ax->by = 12 or
set *pc = 42
While not dismissing this idea, what about my first proposal of
parsing the args first as an expression, and second as a subcommand,
and issuing an error if both parses succeed?