Kill asks the host to signal at once and says when a shell has no job to signal

Kill queued a signal effect for later, so the job it saw running by its marks
could have ended, and another started, before the signal went; and with job
control off the job shares the shell's process group, so the host skipped it
and Kill reported nothing. Kill now calls the host's kill_job while it holds the
turn, and when the only job is the shell's own group says 'Kill: no job to
signal', which also fails a write of Kill to ctl.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 4 insertions, 1 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 2c565ade..ffb509cf 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -112,7 +112,10 @@ started, and `Kill make ls`, those whose line begins with one of the words. A
 command pardes started is a line it typed into a terminal (a word written to
 `exec`, a middle click on one, a `pty/run`), from its shell's start mark (C)
 to its end mark (D); Kill sends its foreground job SIGTERM -- acme posts the
-"kill" note, which ends a process -- and never signals the shell itself --
+"kill" note, which ends a process -- and never signals the shell itself;
+in a shell running without job control (`set +m`) the job shares the
+shell's group, so there is none to signal: Kill says `Kill: no job to
+signal`, and a write of it to `ctl` fails with that --
 and reads every setting there is, one a line, in the words a write of it
 takes (`Verbose on`, `WindowOpacity 70`, `PanelSlide off`, `DumpDir` bare
 for the default directory, `LocationsConfig ...`), so writing what it reads