The kill-by-search guard entry allows a search inside a double-quoted shell string's default: sh -c "kill ${X:-\$(pgrep make)}" is allowed, although with X unset the string's shell runs kill $(pgrep make). The same search written straight into the string, sh -c "kill \$(pgrep make)", refuses, and so does the direct kill ${X:-$(pgrep make)}. The string's re-read takes only spellings and varLead from the written string, never the feeds of the substitutions it holds (payload.go namedPayloads, payloadInput), so the search's output never reaches kill. main allows it too; it was found by the review of the fix for iss-2610110025455728.

Frontmatter

.abcd/work/issues/open/iss-2610110946486757-kill-search-in-a-string-default.md
open on GitHub ↗ · commit history ↗

mentions1

• iss-2610110025455728The rm-unguarded-variable-path guard entry allows an alternative inside a double-quoted shell string: sh -c "rm -rf ${X:+x}/y" is allowed, although the enclosing shell expands ${X:+x} to nothing when X is unset and the string's shell then deletes /y. The direct form, rm -rf ${X:+x}/y, refuses. The cause is the payload re-read: the alternative's texts are the empty text and x, neither names a variable, so the string is written out as rm -rf /y and rm -rf x/y and neither reading leads with a variable (payload.go namedPayloads, varpath.go leadSpelling). It has been allowed since the entry landed in #889. The same re-read misses a default the enclosing shell writes as an escaped reference: sh -c "rm -rf ${X:-\${Y}}/y" and ${X:-\${Y:-}} are allowed, although every shell hands the string rm -rf ${Y}/y. The default's body ends at the first }, so its text is ${Y, and the written text ${Y}/y does not pair with the marked word, whose } follows the mark (payload.go fitsWritten); main allows it too. Separately, the edge fix refuses sh -c "rm -rf ${X:-\\ }/y", whose escaped blank the string's shell keeps as text; this is a deliberate over-refusal (varpath.go emptiedInside) and main refused it too.