[magicant]

[AI-generated]

Fixes #265.

POSIX.1-2024 requires the -b option of the set built-in to have no effect when job control is disabled. This PR makes the shell stop reporting job status changes asynchronously for -b (notify) and --notifyle unless job control is in effect.

No design decision needed the author's input, so every decision below was made without asking. Each entry gives its classification, the strongest alternative, and where it landed. They are ordered by how likely they are to be disputed.

Decisions

1. Job control is checked with doing_job_control_now, not do_job_control (derivable: job control is never performed in subshells). Subshells therefore no longer report their own jobs even with -m -b; before this change, (sleep 0& wait) under -bim printed [2] + Done.
   Alternative: use do_job_control, matching the report before prompts in input.c:260, and keep the in-subshell notification.
   Where: the condition in handle_sigchld (sig.c:704), the notifyle check at the end of handle_traps (sig.c:809), and the report after the external editor in lineedit/editing.c (lineedit/editing.c:2970).
2. --notifyle is ignored without job control too (derivable: without job control, job status is not reported before prompts either, so reporting only during line editing would be inconsistent).
   Alternative: keep the current behavior because --notifyle is a yash extension that POSIX doesn't cover.
   Where: the same three conditions as above.
3. The check is added to each reporting condition (derivable). In handle_sigchld, it goes into the if after do_wait(), because reaping must still happen.
   Alternative: return early at the top of handle_sigchld after reaping.
   Where: sig.c:704.
4. The existing test \j in PS1 and -b option is rewritten for the new behavior (content). It now checks that a finished job stays in the \j count until waited for, and the comment about flakiness is gone because the result no longer depends on timing.
   Alternative: switch it to -m to keep its original intent. With -m, though, jobs are also reported and removed before prompts, so -b would make no visible difference.
   Where: \j in PS1 and -b option without job control (tests/prompt-y.tst:175).
5. Three test cases are added to tests/job-y.tst (content). They are a control case that -bim does notify, -bi +m does not, and a subshell under -bim does not. All three fail without the fix.
   Each test starts the job inside the redirection that captures the notification, because the shell may notice the job's termination at any time after starting it. An earlier version started the job on a separate line and failed on CI when the notification was printed before the redirection.
   Alternative: put them in job-p.tst since this is a POSIX requirement.
   Where: tests/job-y.tst:64, :71, :79.
6. The manuals state the monitor option as a condition in the description of the notify option (content). The first sentence of the notify entry now says the option takes effect when enabled together with the monitor option; the English sentence was rewritten to match the Japanese one. The notify-le entry is left as is because it is described as similar to the notify option, which carries the condition over.
   Alternative: add a separate sentence saying the option has no effect when the monitor option is disabled to both entries, or mention it only in the section on notification timing in job.txt.
   Where: the notify entries in doc/_set.txt:178 and doc/ja/_set.txt:120.
7. NEWS entries are added under 2.62 (derivable: existing convention).
   Alternative: list it as a behavior change ahead of the bug fixes.
   Where: NEWS:14, NEWS.ja:13.

Testing

make test: OK 20310, ERROR 0, SKIPPED 4.

The new tests in tests/job-y.tst also pass when a busy loop is inserted right after starting the job, which reproduced the earlier CI failure.

🤖 Generated with Claude Code