[Lldb-commits] [PATCH] D26883: Demonstrate proposed new Args API

[Jim Ingham via lldb-commits]

> On Nov 29, 2016, at 7:53 AM, Pavel Labath <labath at google.com> wrote:
> 
> On 28 November 2016 at 18:06, Jim Ingham <jingham at apple.com> wrote:
>> backtick parsing is currently incorrect, because it parses the backtick
>> before doing arg parsing, which means it does the substitutions for “raw”
>> commands:
>> 
>> (lldb) expr char *$foo = "some `1 + 2` string"
>> (lldb) expr $foo
>> (char *) $foo = 0x000000010032f100 "some 3 string"
>> 
>> That’s unexpected, and since part of the point of expr is that you can
>> freely cut and paste from a source view into the expr command, it is not
>> desirable.
> Agreed, although I do not think this requirement conflicts with the
> requirements above (btw, I like the raw mode very much)

Raw mode is useful for something like expr, where you know you want to ingest text from the user directly, but IMHO it should be used very sparingly, since it offloads the responsibility for understanding the structure of the command from lldb to the individual command, which in turn adds cognitive load for the user.  The way expr works as a raw commands w.r.t. options, however, makes them for the most part look of a piece with the parsed commands, with some added text at the end.  That's a pretty clear model.  The settings commands, which are also raw, is more inchoate, and has some surprising and some "you can't get there from here" corners as a result.

> 
>> 
>> The most straightforward way to fix this is to make backtick parsing happen
>> as a part of argument parsing - so you would know you were in a raw command
>> and not intervene in the input.
>> 
>> I actually think the full bash quoting rules are overly complex for lldb.
>> Greg was having fun emulating the bash syntax but that seems an
>> unnecessarily complex model for lldb’s command line.  But that may be water
>> under the bridge at this point.
> 
> I'll have to take some of the blame for that. One of my first changes
> on this project was fixing quote processing. :) I think it was a
> strict improvement, as back then we get very inconsistent quoting and
> unquoting rules, which produced very strange results in more
> complicated cases (e.g. prefixing a command with "lldb --" is able to
> run it in a debugger in almost all cases, before it broke down as soon
> as arguments contained quotes). I chose to model it after posix
> shells, as the rules very already quite similar to that, and I thought
> (and still do) that sticking known rules is better than trying to
> invent new ones.

Yes.  I was advocating for a less DWIM set of rules, quotes delimit arguments, conjoining quoted words is not allowed and you are required to backslash any internal quotes.  That is a simple model - kinda of what most programming languages do.  It is sometimes annoying - but in the cases where that matters, mostly expr, the annoying bits aren't parts that the command interpreter has to parse, and raw commands are appropriate there.

The bash rules where "aaa""sss" -> "aaasss" are really useful when you're composing command elements with:

`somecommand``someothercommand` 

where you have no idea whether the result of the `somecommand` will be quoted or not.  But we don't allow that so we didn't need that level of complexity.

Some of the inconsistency you saw is probably because Caroline and I started out thinking of it in this more straightforward way, but then we added a bunch of cool but not necessary complexity.

> 
> I hope I'll find more time to go back to that soon and finish the
> remaining bugs we have mentioned here.
> 

Cool, thanks!

Jim


> pl