Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz <drow@false.org>]

On Tue, Feb 21, 2006 at 10:23:38PM -0800, Jim Blandy wrote:
> How does buildargv-style quoting interact with commands that take
> expressions as arguments?  Aren't there 'set' commands that do this?

Oof.  That's a good question.

Yes, there are.  var_string, var_string_noescape,
var_optional_filename, and var_filename all take literal text.
So do var_boolean, var_auto_boolean, and var_enum.  var_integer,
var_zinteger, and var_uinteger all take expressions.

In the CLI buildargv and the expression parser are clearly
incompatible; we'll have to use it only for non-expression
commands.  Too many languages, et cetera.

For MI it's messier... there's an obvious way in which MI clients can
quote expressions using double quotes, and it would be nice if they did
so.  But read on.

Of the 133 MI commands listed in mi-cmds.c, 53 have an MI
implementation and use the MI parser; 4 have a CLI implementation but
take no arguments; 64 are unimplemented; and 12 pass straight through
to CLI commands with arguments.  That's a gratifyingly small number,
I was afraid it would be much worse.  They are:

  -break-after
  -break-condition
  -break-delete
  -break-disable
  -break-enable
  -break-info
  -exec-arguments
  -file-exec-and-symbols
  -file-exec-file
  -file-symbol-file
  -gdb-set
  -gdb-show

So, some quoting issues there.  For MI, the -gdb-set example in
the manual is very unfortunate:

  -gdb-set $foo=3

And I know that Eclipse will issue:

  -gdb-set auto-solib-add 0

What I am considering at the moment is adjusting mi3 to support only
the second form, i.e. for GDB configuration variables.  Then the
syntax would be:

  -gdb-set IDENTIFIER [IDENTIFIER...] VALUE

After all, you can always use -data-evaluate-expression to accomplish
the other meaning.  Again, this is an incompatible change and would
have to be done only for mi3.  Does it sound like a good idea?  Bad
idea?

Similar problems apply to the other listed MI commands.  For instance,
-exec-arguments ARGS; should it take a single string which is then
split by buildargv into a vector, or should it take freeform text which
is then split into an argument vector?  Well, right now it takes a
literal string, since it just passes the text to CLI "set args". 
That's saved as a string and then passed to create_inferior as a
string, and eventually passed directly to a shell in the fork-child.c
case.  So, as un-MI-like as it is, I think I'd have to leave this one
alone for now - it's just too big a can of worms!

-- 
Daniel Jacobowitz
CodeSourcery