Summary
scripts/e2e-full/lib/discover-tools.sh classifies each tool flag by matching the help line against \bboolean\b (and the sibling numeric patterns). In awk's ERE, \b is the backspace character, not a word boundary — so the pattern never matches, and every non-enum flag is recorded as kind unknown.
$ echo ' --captureCurrent boolean Capture' | awk '{if ($0 ~ /\bboolean\b/) print "MATCH"; else print "NO-MATCH"}'
NO-MATCH
(True for BWK awk — the macOS system awk — and for mawk; gawk spells a word boundary \y.)
Running the discovery block over synthetic describe output in the documented format gives:
udid unknown 1
scale unknown 0
captureCurrent unknown 0
button enum 0 home,back
Only the enum branch works.
Consequence
The kind is consumed downstream by scripts/e2e-full/phases/20-validation.sh, which uses it to build deliberately-wrong payloads. With every flag typed unknown:
- the
bad-type case never fires, because the helper that selects numeric flags always returns empty;
- required numbers and booleans are filled with a placeholder string instead of a type-appropriate wrong value.
So a slice of the validation phase reports as passing while asserting nothing.
Suggested fix
Match on the field rather than with a word-boundary escape — the type column is a whole field in the rendered help line, so a plain $2 == "boolean"-style check (or a [[:space:]]-anchored pattern) is both correct and portable across the three awks. Worth fixing the numeric branch the same way in the same pass, and adding one assertion that the discovery step yields at least one non-unknown non-enum kind, so this cannot silently regress again.
Context
Found while verifying that a new --help legend line would not confuse this parser (#586 / #699). The legend itself is safe — it deliberately does not start with --, and the flag-row parsing works correctly. This is a separate, pre-existing defect in the kind detection only.
Summary
scripts/e2e-full/lib/discover-tools.shclassifies each tool flag by matching the help line against\bboolean\b(and the sibling numeric patterns). In awk's ERE,\bis the backspace character, not a word boundary — so the pattern never matches, and every non-enum flag is recorded as kindunknown.(True for BWK awk — the macOS system awk — and for mawk; gawk spells a word boundary
\y.)Running the discovery block over synthetic describe output in the documented format gives:
Only the enum branch works.
Consequence
The kind is consumed downstream by
scripts/e2e-full/phases/20-validation.sh, which uses it to build deliberately-wrong payloads. With every flag typedunknown:bad-typecase never fires, because the helper that selects numeric flags always returns empty;So a slice of the validation phase reports as passing while asserting nothing.
Suggested fix
Match on the field rather than with a word-boundary escape — the type column is a whole field in the rendered help line, so a plain
$2 == "boolean"-style check (or a[[:space:]]-anchored pattern) is both correct and portable across the three awks. Worth fixing the numeric branch the same way in the same pass, and adding one assertion that the discovery step yields at least one non-unknownnon-enum kind, so this cannot silently regress again.Context
Found while verifying that a new
--helplegend line would not confuse this parser (#586 / #699). The legend itself is safe — it deliberately does not start with--, and the flag-row parsing works correctly. This is a separate, pre-existing defect in the kind detection only.