Quoting, backslashes, CLI and MI

Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

Prompted by some of Andrew's paths-with-spaces patches, and by another
project I'm working on that had to add a var_filename set variable,
I've been looking over the way GDB handles quoting of arguments.
It's a mess.  For most users this is not a big deal; the big losers
are (A) pathnames with spaces in them, and (B) pathnames with backslashes in
them, e.g. DJGPP and MinGW32 paths.

My summary of the current state of commands is after the divider in this
message; it's a bit long, so let's do the more interesting bits first:
what can we do about this, and where do we want to end up?

I think that we want to continue using buildargv-style quoting for CLI
commands, and that it would be desirable to use only MI-style
quoting for MI commands.  Does anyone disagree with this?  The fact
that the two are somewhat inconsistent is regrettable, but
they are nominally independent interfaces.

While the Eclipse CDT does have quoting all messed up for commands like
-file-exec-file (more or less sort of matching the current state,
which is an accident, rather than matching the MI protocol
documentation), it doesn't actually use those commands.  There may
be other cases where the disagreement about backslashes will bite
it, but I couldn't come up with anything in a quick survey.
The only broken thing I found was -environment-cd; the fix
to PR gdb/741 three years ago changed GDB to behave a little
more sensibly, but I think there's still trouble on both the
GDB and Eclipse sides of the fence, and definitely things
don't work if you start Eclipse on a workspace containing
a space.

So I think that we should take this opportunity to fix up all MI
commands to quote like the documentation says they do.  I think
this would have to go into the unfinished -interpreter=mi3 level
and leave -interpreter=mi2 alone, for maximum compatibility.

I'd like to fix up all the CLI and "set" commands to use buildargv style
quoting, too.  "All the set commands" is reasonable and pretty easy
to track down.  "All the CLI commands" is the next best thing to impossible;
it would be a huge amount of work to go through everything that gets
registered as a CLI command that might possibly want a filename or other
quotable arguments.  It'd be nice to do, but I think it's less urgent
considering the amount of work involved.  And Andrew Stubbs has kindly
fixed the worst offenders.

So if folks agree with the general ideas I've put together here,
I can try to sweep for the affected "set" and MI commands.

Andrew Cagney pointed out in a PR that we might need to update the
readline filename completion, too.  I'm not sure if that's still relevant,
it needs a third look.

==

First, CLI commands.  Some of them take arguments literally or in an ad-hoc
manner; others use buildargv() to turn the argument string into an argv
vector.  Buildargv quoting works like this (the implementation is in
libiberty/argv.c):
  - Backslash always escapes the following character.
  - Single quotes and double quotes escape each other and whitespace.
  - Unquoted whitespace separates arguments.

It's not quite the same as POSIX shell quoting or C quoting, but somewhere
in the middle.  But it's fairly simple and seems to work.

buildargv is used in:
  exec-file
  symbol-file
  file
  handle
  interpreter-exec
  info proc
  target mips
  load
  target sim
  run (sim)
  backtrace
  add-symbol-file
  maint print symbols
  maint print psymbols
  maint print msymbols
  path
  directory

Some of these that didn't used to be the case; Andrew Stubbs has been hard
at work on these.  path, directory, and add-symbol-file at least have been
recently changed.  Most of these which actually take filenames also do
tilde expansion.

There are probably some important GDB commands that aren't covered on this
list; but at least it covers the most frequently used file-related commands
(especially "file").  And it's got a reasonably well-defined quoting
strategy.  I suggest that we continue to use it more and more aggressively.
In fact, I'd be happy if we could use it _everywhere_ and have commands take
an argv argument instead of an args string.  Someone would have to do a
study on what commands might be broken by such a change.

==

Next.  I left the "set" commands out of the above; they have their own
quoting rules.

  - var_string variables use C-style escape sequences, but do not strip
    quote marks.  They take the whole rest of the line.  There are fairly
    few of these and I think we could change all six of them.  It's not
    clear that any of them need to handle C-style escape sequences unless
    someone wants to put control characters in their GDB prompt.  All
    the others are in target-specific functionality, some of which is
    scheduled to go away.

  - var_string_noescape is the same, without the C-style escape sequences.
    I think we could change all of these, also - there's only 8.

  - var_filename and var_optional_filename are a bit different. 
    var_filename does tilde expansion and var_optional_filename (often
    used for paths???) does not.  Neither eats quotes or escape characters
    and they both eat to the end of the line.

This is messy.  There are a sufficiently small number of affected commands
that I would recommend changing them all to use buildargv-style quoting,
sooner rather than later, and living with the problems.    

==

Third.  GDB/MI commands.  The MI documentation says:

`PARAMETER ==>'
     `NON-BLANK-SEQUENCE | C-STRING'

`NON-BLANK-SEQUENCE ==>'
     _anything, provided it doesn't contain special characters such as
     "-", NL, """ and of course " "_

`C-STRING ==>'
     `""" SEVEN-BIT-ISO-C-STRING-CONTENT """'

SEVEN-BIT-ISO-C-STRING-CONTENT is not further defined.

The MI implementation does one of two things.  For some commands, those with
an MI-specific implementation - which is 100% a GDB implementation detail
that we really shouldn't be exposing, and don't document, but do somewhat
expose - it uses its own quoting rules.  These are implemented by
mi_parse_argv.  Strings surrounded by double quotes get C escape processing.
Strings not surrounded by double quotes are split at whitespace and
get no further processing - backslashes are passed right through.

For commands _without_ an MI implementation, GDB passes everything after
-the-mi-command and one or more blank spaces to the equivalent CLI command.
Which then parses the arguments however it wants.  This is very confusing.
The MI documentation suggests that these two should be equivalent:
  -file-exec-file .\T_MATH.ELF
  -file-exec-file ".\\T_MATH.ELF"

But since this string gets passed straight to the CLI command "file", this
isn't true - if you don't use the quotes, you need to say this instead:
  -file-exec-file .\\T_MATH.ELF

Which, incidentally, is how Eclipse quotes MI commands; it's got the quoting
rules all buggered up.  Argh!

-- 
Daniel Jacobowitz
CodeSourcery

Re: Quoting, backslashes, CLI and MI

[Paul Koning]

Daniel,

You mentioned tilde expansion in a number of places but didn't
specifically speak of plans to change that.  I would think that having
tilde expansion work at all times whenever file or path names are
processed would be a good thing.

	  paul

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Tue, 21 Feb 2006 16:33:24 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> Prompted by some of Andrew's paths-with-spaces patches, and by another
> project I'm working on that had to add a var_filename set variable,
> I've been looking over the way GDB handles quoting of arguments.
> It's a mess.  For most users this is not a big deal; the big losers
> are (A) pathnames with spaces in them, and (B) pathnames with backslashes in
> them, e.g. DJGPP and MinGW32 paths.

Daniel,

Thanks for a comprehensive summary.  I will read it in depth and
respond by this evening; for now just one comment: the DJGPP port
assumes the user mostly uses forward slashes, not backslashes.
Perhaps doing that on Windows as well will make the job of fixing
what's broken easier.  I don't think it's a bad limitation.

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

On Wed, Feb 22, 2006 at 06:30:30AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 21 Feb 2006 16:33:24 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > Prompted by some of Andrew's paths-with-spaces patches, and by another
> > project I'm working on that had to add a var_filename set variable,
> > I've been looking over the way GDB handles quoting of arguments.
> > It's a mess.  For most users this is not a big deal; the big losers
> > are (A) pathnames with spaces in them, and (B) pathnames with backslashes in
> > them, e.g. DJGPP and MinGW32 paths.
> 
> Daniel,
> 
> Thanks for a comprehensive summary.  I will read it in depth and
> respond by this evening; for now just one comment: the DJGPP port
> assumes the user mostly uses forward slashes, not backslashes.
> Perhaps doing that on Windows as well will make the job of fixing
> what's broken easier.  I don't think it's a bad limitation.

Thanks; no rush on this - I'll find something else to keep me busy
tomorrow and be back to it.

I don't actually know which form of paths current Windows MI clients
use.  I agree that it would be convenient if they mostly used forward
slashes; but it looks like Eclipse uses native backslashed paths
primarily, so I've some interest in supporting them (to perturb Eclipse
as little as possible).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Quoting, backslashes, CLI and MI

[Jim Blandy]

On 2/21/06, Daniel Jacobowitz <drow@false.org> wrote:
> I think that we want to continue using buildargv-style quoting for CLI
> commands, and that it would be desirable to use only MI-style
> quoting for MI commands.  Does anyone disagree with this?  The fact
> that the two are somewhat inconsistent is regrettable, but
> they are nominally independent interfaces.

I think that's the right thing.  I don't think it's a significant inconsistency.

How does buildargv-style quoting interact with commands that take
expressions as arguments?  Aren't there 'set' commands that do this?

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

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

Re: Quoting, backslashes, CLI and MI

[Jim Blandy]

On 2/22/06, Daniel Jacobowitz <drow@false.org> wrote:
> 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.

That's my feeling too.

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

Yeah --- this seems to me to be taking an overloading of "set"
designed to make life easier for humans and carrying it through to a
machine interface, where it's not helpful, and where the ambiguity is
problematic.  I don't think this form of -gdb-set should be (or ever
have been) supported.

> 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.

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

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

Re: Quoting, backslashes, CLI and MI

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> 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 :-)

remote-sim.c already uses build_argv for its args.

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Tue, 21 Feb 2006 16:33:24 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> I think that we want to continue using buildargv-style quoting for CLI
> commands, and that it would be desirable to use only MI-style
> quoting for MI commands.

I agree.  But that means MI commands that delegate to CLI will have to
process the arguments to modify the quoting, right?

> So I think that we should take this opportunity to fix up all MI
> commands to quote like the documentation says they do.

It would be good to fix that now, yes.

However, I Think we need 2 different styles of quoting: one for file
names, the other for strings.  Otherwise, supporting the Windows
backslashes will be hard.  Also, there are messy cases such as this:

    (gdb) break "foo bar.c":'MyClass::MyMethod'

(I'm not even sure I quoted it correctly ;-).  Can we really use the
same quoting rules for both the file-name and class/method name in
such situations?

> I'd like to fix up all the CLI and "set" commands to use buildargv style
> quoting, too.

If you agree with me on the two quoting styles, you will also agree
that we need two different flavors of buildargv.

> Andrew Cagney pointed out in a PR that we might need to update the
> readline filename completion, too.  I'm not sure if that's still relevant,
> it needs a third look.

It's relevant, at least wrt backslashes in Windows file names: if you
type TAB with backslash being the last character, completion won't
work (it does TRT when there are backslashes further to the left of
the cursor, though).  Also, quoted file names, with or without
whitespace, aren't completed correctly, no matter if they use forward
or backslashes.

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

On Wed, Feb 22, 2006 at 07:19:05PM +0000, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >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 :-)
> 
> remote-sim.c already uses build_argv for its args.

I think that the number of people who pass complicated args to programs
run on the simulator is probably much smaller than the number who do so
to programs run natively; fork-child.c will trump in this case.  For
instance, local system filenames.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Tue, 21 Feb 2006 23:35:27 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> I don't actually know which form of paths current Windows MI clients
> use.  I agree that it would be convenient if they mostly used forward
> slashes; but it looks like Eclipse uses native backslashed paths
> primarily, so I've some interest in supporting them (to perturb Eclipse
> as little as possible).

If we want to support backslashes on Windows _and_ backslash-escaping
without lots of ugly system-dependent code, then we will have to
require to double each backslash.  Which I think will be inconvenient.

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Wed, 22 Feb 2006 09:29:53 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> -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!

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.

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Wed, 22 Feb 2006 13:01:37 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> 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.

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.

> 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.

Yes, and I Think this is The Right Thing to do, for the same reasons.

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

On Wed, Feb 22, 2006 at 09:22:18PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 21 Feb 2006 16:33:24 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > I think that we want to continue using buildargv-style quoting for CLI
> > commands, and that it would be desirable to use only MI-style
> > quoting for MI commands.
> 
> I agree.  But that means MI commands that delegate to CLI will have to
> process the arguments to modify the quoting, right?

Right - or stop delegating to the CLI, which is what I think I would
do.  Especially since it turned out that there were only about a dozen.

> > So I think that we should take this opportunity to fix up all MI
> > commands to quote like the documentation says they do.
> 
> It would be good to fix that now, yes.
> 
> However, I Think we need 2 different styles of quoting: one for file
> names, the other for strings.  Otherwise, supporting the Windows
> backslashes will be hard.  Also, there are messy cases such as this:
> 
>     (gdb) break "foo bar.c":'MyClass::MyMethod'
> 
> (I'm not even sure I quoted it correctly ;-).  Can we really use the
> same quoting rules for both the file-name and class/method name in
> such situations?

Well, are you talking about the CLI here, or about the MI?

Supporting Windows backslashes isn't hard - but we would have to
document that they must be doubled (A) on the CLI, and (B) within
double-quoted MI arguments.  Which is already how things work in many
cases; for instance:

(gdb) file .\T_MATH.elf
.T_MATH.elf: No such file or directory.
(gdb) file .\\T_MATH.elf
Reading symbols...

I'd like for the quoting rules to be independent of what's being
quoted.

Break is a particularly confusing example that I had not considered in
depth.  linespec.c needs to receive the quotes, because they affect how
the linespec is interpreted (which I think is somewhat horrid, but
anyway, moving on, leave that for another day).  In MI, this means you
ought to be doing things like this, for your example:

(gdb) break "foo bar.c":'MyClass::MyMethod'

-break-insert "\"foo bar.c\":'MyClass::MyMethod'"

Fortunately, -break-insert is already a real MI command - so this is
already how it behaves.

> > I'd like to fix up all the CLI and "set" commands to use buildargv style
> > quoting, too.
> 
> If you agree with me on the two quoting styles, you will also agree
> that we need two different flavors of buildargv.

I don't think I agree, although Jim's pointed out "set args" and
var_*integer, so not all set commands can be handled this way.
Some new documentation will definitely be written!

> > Andrew Cagney pointed out in a PR that we might need to update the
> > readline filename completion, too.  I'm not sure if that's still relevant,
> > it needs a third look.
> 
> It's relevant, at least wrt backslashes in Windows file names: if you
> type TAB with backslash being the last character, completion won't
> work (it does TRT when there are backslashes further to the left of
> the cursor, though).  Also, quoted file names, with or without
> whitespace, aren't completed correctly, no matter if they use forward
> or backslashes.

Thanks.  Another day, another bug.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

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

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

On Tue, Feb 21, 2006 at 04:42:32PM -0500, Paul Koning wrote:
> Daniel,
> 
> You mentioned tilde expansion in a number of places but didn't
> specifically speak of plans to change that.  I would think that having
> tilde expansion work at all times whenever file or path names are
> processed would be a good thing.

Makes sense to me.  They should probably be left alone in "set args",
though, so the current use of var_optional_filename would need
adjustment.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Quoting, backslashes, CLI and MI

[Daniel Jacobowitz]

On Wed, Feb 22, 2006 at 09:24:10PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 21 Feb 2006 23:35:27 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > I don't actually know which form of paths current Windows MI clients
> > use.  I agree that it would be convenient if they mostly used forward
> > slashes; but it looks like Eclipse uses native backslashed paths
> > primarily, so I've some interest in supporting them (to perturb Eclipse
> > as little as possible).
> 
> If we want to support backslashes on Windows _and_ backslash-escaping
> without lots of ugly system-dependent code, then we will have to
> require to double each backslash.  Which I think will be inconvenient.

For the CLI, yes, this is somewhat inconvenient.  I think the
consistency benefits trump that; the user can always enter forward
slashes instead.  And we already need to double backslashes in some
places (like "file").

For the MI, it's not at all inconvenient; e.g. Eclipse already has code
to do this in most places (though as I mentioned, it's not quite
correct).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Quoting, backslashes, CLI and MI

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Tue, Feb 21, 2006 at 04:42:32PM -0500, Paul Koning wrote:
 >> Daniel,
 >> 
 >> You mentioned tilde expansion in a number of places but didn't
 >> specifically speak of plans to change that.  I would think that
 >> having tilde expansion work at all times whenever file or path
 >> names are processed would be a good thing.

 Daniel> Makes sense to me.  They should probably be left alone in
 Daniel> "set args", though, so the current use of
 Daniel> var_optional_filename would need adjustment.

Agreed, given that "set args" is supposed to treat the entire argument
list as literal without any processing.

(Hm... should there be a flavor of "set args" that does shell-style
expansion of the args list?  That sure would be handy for cases where
I want to debug a program that's being handed a wildcard, or some
similar expanded argument, and I end up having to expand it manually
when inside GDB...)

     paul

Re: Quoting, backslashes, CLI and MI

[Mark Kettenis]

> Date: Wed, 22 Feb 2006 14:57:53 -0500
> From: Paul Koning <pkoning@equallogic.com>
>
> (Hm... should there be a flavor of "set args" that does shell-style
> expansion of the args list?  That sure would be handy for cases where
> I want to debug a program that's being handed a wildcard, or some
> similar expanded argument, and I end up having to expand it manually
> when inside GDB...)

But we already have that flavor of "set args"; it's what "set args"
;-).  When we start an inferior process, we do so by starting a shell,
which will expand the argument list for you.

Mark

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Wed, 22 Feb 2006 14:34:10 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> > I agree.  But that means MI commands that delegate to CLI will have to
> > process the arguments to modify the quoting, right?
> 
> Right - or stop delegating to the CLI, which is what I think I would
> do.

If that's not hard to do, then it's probably for the better to stop
delegating.

> > However, I Think we need 2 different styles of quoting: one for file
> > names, the other for strings.  Otherwise, supporting the Windows
> > backslashes will be hard.  Also, there are messy cases such as this:
> > 
> >     (gdb) break "foo bar.c":'MyClass::MyMethod'
> > 
> > (I'm not even sure I quoted it correctly ;-).  Can we really use the
> > same quoting rules for both the file-name and class/method name in
> > such situations?
> 
> Well, are you talking about the CLI here, or about the MI?

I thought I was talking about both, but maybe we need to think about
it some more.  Your description seemed to hint that 2 different
quoting styles already existed at least for the CLI case.  And it
seemed to me that trying to unify them would be a lot of unneeded
work, especially since I'm not at all sure they can be unified in a
useful way.

> Supporting Windows backslashes isn't hard - but we would have to
> document that they must be doubled (A) on the CLI, and (B) within
> double-quoted MI arguments.

If this would be acceptable to users, I don't mind.

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Wed, 22 Feb 2006 14:50:32 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org, jimb@red-bean.com
> 
> 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.

Thanks for the additional explanations, but I don't see where I said
two contradictory things.  Anyway, I agree with your examples and with
their interpretation, so I think we agree in general here.

Re: Quoting, backslashes, CLI and MI

[Eli Zaretskii]

> Date: Wed, 22 Feb 2006 14:57:53 -0500
> From: Paul Koning <pkoning@equallogic.com>
> Cc: gdb@sourceware.org
> 
> Hm... should there be a flavor of "set args" that does shell-style
> expansion of the args list?

I don't think we should expand it ourselves.  It could lead to
incorrect expansion; e.g., consider the case where the inferior runs
in a different directory or has different user credentials.