Re: Strangeness in set command

[Michael Snyder <msnyder@specifix.com>]

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?