A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1966 ====================================================================== Reported By: stephane Assigned To: ====================================================================== Project: 1003.1(2024)/Issue8 Issue ID: 1966 Category: Shell and Utilities Tags: tc1-2024 Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Stephane Chazelas Organization: User Reference: Section: current/previous job in basedefs, jobs, fg, bg utilities Page Number: (page or range of pages) Line Number: (Line or range of lines) Interp Status: Pending Final Accepted Text: https://www.austingroupbugs.net/view.php?id=1966#c7371 Resolution: Accepted As Marked Fixed in Version: ====================================================================== Date Submitted: 2025-12-21 11:17 UTC Last Modified: 2026-02-06 09:11 UTC ====================================================================== Summary: Current/previous job definition scattered and ambiguous ======================================================================
---------------------------------------------------------------------- (0007372) stephane (reporter) - 2026-02-06 09:11 https://www.austingroupbugs.net/view.php?id=1966#c7372 ---------------------------------------------------------------------- Re: https://www.austingroupbugs.net/view.php?id=1959#c7370 > the job that was most recently suspended, placed in the > background, or run as a background job We may want to clarify what "placed in the background" means. AFAIK, the only ways (as already noted in the bug description) to "place" a job in the background are to "run it as a background job" and suspend them whilst they are in foreground, which here would seem to make that "placed in background" redundant. The "bg" utility is to "resume, still in background" (send SIGCONT to the process group), while "fg" puts a job in foreground, resumes it if suspended and waits for one of the processes in the job to terminate or be suspended again. I've tried to check whether any shell was compliant to this new specification and among mksh, yash, bash, zsh, dash, ksh93, only ksh93 seems to be as it's the only one that seems to maintain the job table in terms of priority for that "current job" (and diverges from all other shells and by not always priotising suspended jobs). dash (and presumably other ash-based shells) also does that ordering, but since it prioritises suspended jobs, as was the spirit of job control as originally implemented on BSDs, (and if not makes "bg" alone less useful for instance), once resumed in background, that background job remains the current job: $ dash $ sleep 1h & $ sleep 2h ^Z[2] + Stopped sleep 2h $ sleep 3h & $ jobs [2] + Stopped sleep 2h [3] - Running sleep 3h [1] Running sleep 1h Stopped job is current as allowed (previously required) by the proposed text. $ bg [2] sleep 2h $ jobs [2] + Running sleep 2h [3] - Running sleep 3h [1] Running sleep 1h %2 still current job which sounds like is not compliant to the new text unless the: > the job that was most recently suspended, placed in the > background, or run as a background job shall be used. Is to be understood as: 1. most recently suspended job if any of the jobs have ever been suspended. 2. If not: most recently "placed in background" if any of the jobs have even been "placed in background". 3. If not: most recently run as a background job. (In which case ksh93 would not be compliant) as otherwise %3 would need to be the current job as it was "placed in the background" (or "run as a background job") after %2 was suspended. In any case, bash, zsh, mksh, yash are not compliant (because they don't order that list or some other reasons). In other words, I suggested two resolutions, one that would (AFAICT) make all shells but ksh compliant and was more in the spirit of the current specification and another one that would make all shells compliant, but instead, the currently proposed resolution makes all shells but ksh non-compliant, ksh being the one that goes against the fundamental principle that suspended jobs should be prioritised for the current/previous job appointment. IMO, that's not OK, because it doesn't help. First, IMO, POSIX specifying interactive use behaviour has little benefit. It's invaluable to standardise the shell language to write portable scripts, but trying to tightly specify user interaction is more likely to hinder progress than anything. One could argue that specifying interactive use experience means users from one system/shell can expect not to be disoriented when jumping to another system/shell, but in this instance, the resolution makes an important point unspecified and on the other hand mandates things that are less important and in practice vary between implementations. If there's a suspended job, people expect that to be the current job as that's what most shells do and even what POSIX currently requires. ksh breaks that expectation. On the other end, what rules determine which job will become the current job once the current and previous jobs have terminated or all jobs have been resumed matters less, as nobody will manage to remember those rules and compute them mentally so would need to refer to the "jobs" output to know which it is or would refer to jobs by their number or search string instead. About the "previous job" definition: > In the context of job control, the job that will be used as >the default for the fg or bg utilities if the current job exits A process can "exit", by way of the exit() function for instance, but what does it mean for a "job" to exit? For instance, (sleep 60 & sleep 1) Starts a foreground job with a process running sleep 60, one running sleep 1 and possibly a shell one waiting for sleep 1, After one second, the one running sleep 1 (and the shell one waiting for it if any) exit()s, while the one running sleep 60 is still running. However, as far as the interactive shell that started that job is concerned, that job is gone as there's only one process in that job it's waiting for (the one that runs the subshell if any and possibly subsequently sleep 1 or waited for that sleep 1 in those shells that implement subshells as child processes and don't optimise out the fork for sleep 1). My: > what the current job would be in the absence of whichever job > is currently appointed as the current job. Was attempting to clarify it, and avoids having to define what it means for a job to "exit" though still leaves it unclear what makes a job "absent" or "present". Note that even "running job" or "suspended job" are potentially ambiguous as some processes in the job could be suspended and some running, but maybe that's for another bug. Issue History Date Modified Username Field Change ====================================================================== 2025-12-21 11:17 stephane New Issue 2026-01-06 10:04 geoffclare Project 1003.1(2013)/Issue7+TC1 => 1003.1(2024)/Issue8 2026-02-05 17:20 geoffclare Note Added: 0007371 2026-02-05 17:21 geoffclare Status New => Interpretation Required 2026-02-05 17:21 geoffclare Resolution Open => Accepted As Marked 2026-02-05 17:21 geoffclare Interp Status => Pending 2026-02-05 17:21 geoffclare Final Accepted Text => https://www.austingroupbugs.net/view.php?id=1966#c7371 2026-02-05 17:21 geoffclare Tag Attached: tc1-2024 2026-02-06 09:11 stephane Note Added: 0007372 ======================================================================
