Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz <drow@false.org>]

On Wed, Feb 22, 2006 at 09:39:55AM -0800, Jim Blandy wrote:
> > 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!
> 
> You'd have to rework a lot of code to make the quoting happen earlier.

Actually, there's two different possibilities here, and I think I
focused on the wrong one.

1.  We want -exec-arguments to take MI-quoted individual arguments,
    which are then passed as argv elements to the program.

2.  We want -exec-arguments to take a single MI-quoted argument,
    which is the value to set the argument string to, for the target
    and/or shell to handle however they deem appropriate.

Doing (1) would require a lot of reworking, but more-or-less-kind-of
preserve the current semantics, for common cases - it would probably be
incompatible at the edge cases.  Doing (2) would be a clear MI
interface change, but the result seems somewhat sensible.  WDYT?

Then there's the question of what to do with CLI "set args".  People
use this today and it is passed literally to the program, without any
interpretation of quotes or escapes - if you want that to happen you
wait for the shell to do it.  I don't think that we can really change
that - we can bump the interface version on MI, but we can't really
bump it on our CLI users' fingers :-)

So CLI "set args" will need to continue being unescaped, one way or
another.

-- 
Daniel Jacobowitz
CodeSourcery