Path: ...!weretis.net!feeder8.news.weretis.net!news.szaf.org!inka.de!mips.inka.de!.POSTED.localhost!not-for-mail
From: Christian Weisgerber <naddy@mips.inka.de>
Newsgroups: comp.unix.shell
Subject: Re: When/why does the shell (bash) (sometimes) not re-cycle job IDs?
Date: Sat, 11 May 2024 22:44:03 -0000 (UTC)
Message-ID: <slrnv3vt5j.1gfp.naddy@lorvorc.mips.inka.de>
References: <v1oi0d$rrf5$3@news.xmission.com>
Injection-Date: Sat, 11 May 2024 22:44:03 -0000 (UTC)
Injection-Info: lorvorc.mips.inka.de; posting-host="localhost:::1";
	logging-data="51409"; mail-complaints-to="usenet@mips.inka.de"
User-Agent: slrn/1.0.3 (FreeBSD)
Bytes: 1729
Lines: 23

On 2024-05-11, Kenny McCormack <gazelle@shell.xmission.com> wrote:

> I tried it a few times, but could not get back the #1 slot.

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

I've only cursorily glanced over the code history, but I think it's
been like this in csh(1) since its initial import into the BSD
repository in 1980, and other shells have copied the behavior.

> Eventually, I exited jobs 2 & 3, and then re-launched ssh somesystem and it
> came out as job #1, after which I was able to re-construct jobs 2 & 3 and
> then things were as they should be.  But should this hack be necessary?

As I accidentally discovered while looking at the code, csh(1) tries
to recycle smaller job IDs once it goes beyond 9.  tcsh(1) preserves
that behavior to this day.

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.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de