Re: When/why does the shell (bash) (sometimes) not re-cycle job IDs?

On 12.05.2024 02:14, Lawrence D'Oliveiro wrote:

On Sat, 11 May 2024 22:44:03 -0000 (UTC), Christian Weisgerber wrote:
 

If no job is running, a new job gets 1, otherwise new jobs are numbered
consecutively.

 
Job numbers are reused after it has notified you of termination of the
previous job. At least in Bash.

Also the same behavior in Ksh, ever since I can remember; lowest job
number "available" gets re-used first. (Where "available" means that
its finishing status has been reported and not that the job finished.)

 
I’ve often wondered why shells don’t use poll/select-based event loops.
Then they can notify you of job termination immediately, instead of
waiting for you to press return.

It may be considered undesired in an interactive shell to unnecessarily
spoil the output of other running processes. If job output would be
written asynchronously then you could also easily miss the output of
the job control system. Likely two undesired effects.

 

I offer no opinion on this, nor on the Plan 9 assertion that job control
is a poor hack and you should just open another window.

I'm using a lot shell windows, subshell instances, and also background
jobs. Each for different sets of use cases.

For me it's much faster to fire up a background job than opening a new
window. And a lot less overhead (typing, switching, timing, resources).

Sounds more like a "Use the hammer for this screw!" suggestion to me.

Janis

[...]