Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz <drow at false dot org>]

Hi Eli,

I think I haven't explained the issue with -exec-arguments very
clearly, since your two responses are contradictory.  I agree
with one of them :-)  Let me try to straighten it out.

On Wed, Feb 22, 2006 at 09:26:14PM +0200, Eli Zaretskii wrote:
> We should leave it alone, and not only because it's a mess:
> "-exec-arguments" _should_ pass its argument to the shell, it should
> not second-guess the shell features, nor reinvent them.

[Second-guessing I certainly agree with, reinventing the shell features
is a separate discussion which we've had elsewhere; but that's
a different topic.]

On Wed, Feb 22, 2006 at 09:29:15PM +0200, Eli Zaretskii wrote:
> > 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.
> 
> I think we should take (2).  We shouldn't second-guess or reinvent
> shell features.  There's a good chance that the string is actually
> coming from a user who typed it, in which case it will be in the form
> we type at the shell's prompt.  So it should go to the shell for
> interpretation.

I agre that we want #2.  But this isn't the same as leaving it alone;
#1 is actually closer to leaving things alone.  Here's one example:

  -exec-arguments a b "c d"

Today, the shell would be invoked with this string:
  PROGRAMNAME a b "c d"

Eventually the program would be invoked with three arguments: a, b, c d.
In #1, the same thing would happen.  In #2, this would be a syntax
error.

Here's another example:
  -exec-arguments "\""

Today, the shell would be invoked with "\"", which would eventually
reach the program as a single double quote in the first argument.
In #1 the same thing would happen.  In #2 the shell would probably
complain - it would be run as:
  PROGRAMNAME "

Here's another example to consider:
  -exec-arguments "\n"

Today this would run the shell with the command:
  PROGRAMNAME "\n"

Depends on your shell, but generally speaking, you ought to get a
backslash and an 'n' in the first argument.  But #1 is going to pass
a newline!  And so would #2.

And this one:
  -exec-arguments "\n" "\n"

Today, two backslash-followed-by-n arguments.  #1, two newline
arguments.  #2, syntax error.

The advantage of #2 is that we have a well defined way to put any
characters at all into the string using MI.  Everything gets escaped
twice: once by the MI layer and once by the shell.  We document that,
and everyone can deal with it robustly.

> > So CLI "set args" will need to continue being unescaped, one way or
> > another.
> 
> Yes, and I Think this is The Right Thing to do, for the same reasons.

I agree that this is the right thing to do (though a little tricky).

-- 
Daniel Jacobowitz
CodeSourcery