For convenience reasons the 'settings set' commands parsing logic is hand-written and doesn't strictly follow
the usual LLDB command rules. The help page gives the following syntax:
settings set [-f] [-g <filename>] -- <setting-variable-name> <value> settings set <setting-variable-name> <value>
For the most part LLDB follows that syntax, but the current parser for the command syntax has some strange quirks
that are probably best demonstrated with some examples:
# Quotes break the parser (lldb) settings set "prompt" foo error: mismatched quotes # Arguments starting with '-' behind the property name are recognized as command flags. (lldb) settings set target.run-args -v error: unknown or ambiguous option # Even when working around via `--`, the settings write/read functionality doesn't support it. (lldb) settings set -- target.run-args -v (lldb) settings show target.run-args target.run-args (arguments) = [0]: "-v" (lldb) settings write -f ~/set (lldb) settings read -f ~/set Executing commands in '/Users/teemperor/set'. error: unknown or ambiguous option # Also using the `-g` with a filename that contains the property name leads to some strange results. (lldb) settings set -g ~/prompt-settings prompt foo -settings prompt foo # <- this is the new prompt
We could just change the syntax to what the other 'raw' commands are using, but that would obviously
break everyone's script and all the settings files LLDB has generated for users.
So instead this is a partial rewrite of the old settings parser that tries to support the previous syntax
(with some minor exceptions) but also address the issues above.
In essence the patch does two things:
First we incrementally try to parse the argument list passed by the user until we find the property name.
Only the flags up until the property name are considered command flags as we promised in the help page.
This should fix issues related to passing values starting with - leading to error: unknown or ambiguous option.
Afterwards we explicitly hop over all the command flags we found in the first part instead
of just searching the input string for the property name. This way having the property name
occur in one of the arguments (e.g. -g path/to/property-name.settings) doesn't cause LLDB
to write set the property to whatever follows the first "property name" occurrence.
From what I can see the only use case this breaks is clearing a property value by doing settings set <name> -f
(as now we treat the -f as the value that <name> should be set to).
This is a bit of a weird example, since it doesn't in fact have a settings name. Did you mean to have some settings name between "my-command-args" and "-o"?