Date: Sat, 15 Aug 2026 07:31:00 -0600
From: Stan Marsh <[email protected]>
Message-ID: <[email protected]>
| This is in the category of "not really a bug, but just annoying"
It isn't a bug, is a feature, and yes, occasionally it can be annoying.
Without the current behaviour, it is hard for a script using jobs (set -m)
to create new ones and keep track of what %n applies to each one, which
is possible now, as until some of them are waited for (and cleaned up)
the next is always n+1 ... if the shell just started reusing job numbers
because some process had exited, that would be unworkable.
At the most, a change to this wouldn't be workable without an enabling option.
Further, I doubt you'd find it nearly as appealing as you imagine,
as if the shell was to reuse vacant job numbers, then the next job
it creates will get the one just vacated by an exited process, even
if it isn't the one you would want to replace that one. You'd be
continually killing and restarting things trying to get the job numbers
correct.
What might be more useful would be a built in command, like
usejob -j N command .....
(or something like that) which would ask the shell to use a particular
job number (and fail if that job number is in use). (Syntax and name
are obviously invented, and could be anything desirable). One could
even perhaps just allow
%1 command ...
to set the job number to 1 using the already (semi-) existing %n commands.
(Again, error if %1 is already in use).
kre
ps: I use jobs a lot, and I also see this kind of thing (and the NetBSD
shell behaves the same way). I also use lots and lots of xterm windows,
and also tmux for sharing windows amongst multiple whatevers. Those all
achieve different results, each is appropriate in some cases, not others.
