It makes more sense to handle escapes in configuration strings when we
parse them, rather than after-the-fact when we handle notifications that
use the relevant config options.
Do this in the proper backslash handler; rather than a naive string
replace which doesn't allow the backslash to be escaped (`\\n` => 0x5C0x0A
rather than 0x5C0x6E).
it to the proper backslash handler
The current behavior is
- If the value contains a double-quote:
- 1. Verify that it must contains at least two quotes.
- 2. If one of the quotes is the first character, trim it.
- 3. If one of the quotes is the last character, trim it.
- Else:
- 1. Trim a trailing comment from the value.
This has the effect that
`key = "value" # comment` => `value" #comment`
This is surprising and almost certainly not what the user wants.
However, it allows simple nested quotes like:
`key = "A string "with quotes""` => `A string "with quotes"`
Fix the brokenness of the first example at the expense of breaking the
second. A user seeking that value will now have to type:
key = "A string \"with quotes\""
Do this by treating double-quote as a toggle that simply changes whether
`;` and `#` start comments (not too different than Bash using it to toggle
field separation).
In order to have strings that contain a literal double-quote, add
rudimentary support for backslash-escaping. For now, only recognize
double-quote and backslash-itself; anything else is undefined; and the
program is free to do whatever it likes with them; for now, silently treat
the backslash as an ordinary character.
Note that this formulation of quoting implies that backslash-escaping works
identically both inside and outside of quotes.
string_to_argv parsing was very simplistic and didn't properly handle
quotations. Since we are already using glib, g_shell_parse_argv serves
the same purpose with much better parsing and error handling.
