Merge pull request 'Issue 294: a quoted value given to the controller's command line cannot hold a quote' (#169) from issues/294-a-quoted-value-cannot-hold-a-quote into main

2026-10-07 17:48:03 +00:00
parent 79cadf6c96 725ad51606
commit d96644e827
1 changed files with 33 additions and 0 deletions
@@ -0,0 +1,33 @@
+---
+status: open
+opened: 2026-10-07
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 294. A quoted value cannot hold a quote
+
+## Symptom
+
+On 2026-10-07 a machine's role was set through the controller's `command` verb, which takes one
+command line: `settings set claude-code '{"role":"the operator's laptop …"}' --node <machine>`. The
+value is a JSON object inside single quotes, and the text inside it contains an apostrophe. The line
+was cut at that apostrophe and the call failed. The same setting, passed through the `settings` verb
+with its `values` argument as a field of its own, was taken at once.
+
+So any value given through `command` that itself contains a single quote cannot be passed at all. The
+argument line has no way to escape a quote inside a quoted value, and nothing says so: the caller sees
+a parse failure of the JSON, not the reason.
+
+## Why it matters beyond this instance
+
+`command` is how a shell line reaches the controller from anywhere, and settings, descriptions and
+reasons are ordinary text, where an apostrophe is common. A value that cannot be said in one form
+and can in another is a trap, and the failure names the wrong cause.
+
+## Not yet decided
+
+Whether `command` should accept an escape inside quoted values (as a shell does), refuse a line
+with an unbalanced quote naming the position, or both; and whether every verb that a `command` line
+reaches should also say which verb takes the value as its own field.