`17-guard.md:1038` lists a pid list a kill reads through a variable or a file, or from a `ps | grep` chain, as unseen. `iss-2611040555239973` and `iss-2611040555220611` record the forms that block as `kill-by-search`. They do not record what stays true: `kill $(cat pidfile)` and a bare `kill $p` still allow, so removing the clause outright would leave the chapter implying those are seen. `p=$(ps aux | grep foo); kill $p` also blocks.

Frontmatter

.abcd/work/issues/open/iss-2611060810012471-17-guard-md-1038-lists-a-pid-list-a-kill.md
open on GitHub ↗ · commit history ↗

mentions2

• iss-2611040555220611.abcd/development/brief/04-surfaces/17-guard.md:809 and 1019-1024 say an allow does not see what a variable carries from an earlier command, with `p=$(pgrep make); kill $p` as the example, and call whether to read it an open ruling. A variable assigned on the same line is read and blocked: that example, a process-substitution path handed to bash, a command held in a variable and run through eval or sh -c, and pkill as a variable's value, each exit 1. Only a value set before the line stays allowed. commands/guard.md:683 documents this.
• iss-2611040555239973.abcd/development/brief/04-surfaces/17-guard.md:1013-1014 says an allow does not see a pid list a kill reads through a file or from a `ps | grep` chain. `ps aux | grep make | xargs kill`, the awk and `kill $(...)` forms and `pgrep make > p; kill $(cat p)` all exit 1 under kill-by-search. commands/guard.md:992 states that a filtered ps listing is a search.