This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Quoting, backslashes, CLI and MI
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
- References:
- Quoting, backslashes, CLI and MI
- Re: Quoting, backslashes, CLI and MI
- Re: Quoting, backslashes, CLI and MI
- Re: Quoting, backslashes, CLI and MI
- Re: Quoting, backslashes, CLI and MI
- Re: Quoting, backslashes, CLI and MI
- Re: Quoting, backslashes, CLI and MI