I recently experienced the following situation. I have 3 background jobs,
all interactive shells, nicely arranged as job #1, job #2, and job #3.

When I do the "j" command ("j" is aliased to "jobs -l"), I get something
like:

[1]+ <number> Running ssh somesystem &
[2] <number> Running ssh someOthersystem &
[3] <number> Running sudo bash &

Now, I did %1 and (accidentally) logged out of somesystem. Now, when I do
"j", I get:

[2] <number> Running ssh someOthersystem &
[3] <number> Running sudo bash &

So, I ssh back into somesystem and do the usual ~^Z and find that it is now
job #4. I want it to be job #1, like it was before.

Now, usually, when something like this happens, it is because some file or
some other resource is still open on the old object, so it cannot be
recycled. But this doesn't seem to be the case here. I tried it a few
times, but could not get back the #1 slot.

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?

--
In American politics, there are two things you just don't f*ck with:

1) Goldman Sachs
2) The military/industrial complex

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

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.

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.

> 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 use job control, I use both tabs and windows in my favourite terminal
emulator (Konsole), and I use screen when SSH’ing to a client’s remote
test server. I have a bunch of containers running on the latter to try out
various things, and each one has its own session within screen.

On Sun, 12 May 2024 00:14:08 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <v1p1kf$2ake7$1@dont-email.me>:

> 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.

With bash: set -b

--
-v

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

> [...]

In article <v1p1kf$2ake7$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> 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.

No, they don't. That's the point.

As Christian notes, they only get reused (starting over at #1) if there
aren't any jobs.

--
"Every time Mitt opens his mouth, a swing state gets its wings."

(Should be on a bumper sticker)

In article <v1p6hr$2btq7$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>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.)

Nope. Sorry.

--
Those on the right constantly remind us that America is not a
democracy; now they claim that Obama is a threat to democracy.

In article <slrnv3vt5j.1gfp.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
>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.

Yeah, that seems to be it. I wonder why...

....
>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.

That's weird. I wonder why...

>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.

Well, certainly, having lots of windows open (and having things like
screen/tmux) is nice and is the modern way, but this is one situation where
I actually like having these other things running as jobs. If they were in
other windows (and/or in screen/tmux windows), I'd lose track of them.

As it is, I sometimes forget they are there.

--
Politics is show business for ugly people.

Sports is politics for stupid people.

On Sun, 12 May 2024 03:38:03 +0200, Janis Papanagnou wrote:

> On 12.05.2024 02:14, Lawrence D'Oliveiro wrote:
>
>> 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.

Fair, but it could still do the report while waiting for you to input your
next command.

Bash uses GNU Readline, so it has the partial line you’ve input already,
and can redisplay it after the message, to allow you to continue typing
from where you left off.

DEC’s old VMS OS had a special terminal read operation called “read-with-
prompt”. If your partial input got messed up, it could be redisplayed,
along with the prompt string that was included in the read operation.

> If job output would be
> written asynchronously then you could also easily miss the output of
> the job control system.

That happens anyway. The only thing background processes are blocked from
doing is input from the controlling terminal.

On 2024-05-12, Lawrence D'Oliveiro <ldo@nz.invalid> 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.

Demonstrably false:

bash$ sleep 10 &
[1] 64882
bash$ sleep 200 &
[2] 64883
bash$ sleep 300 &
[3] 64884
bash$ sleep 400 &
[4] 64885
[1] Done sleep 10
bash$ sleep 500 &
[5] 64886
bash$ sleep 600 &
[6] 64887

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

On 12.05.2024 04:30, Kenny McCormack wrote:
> In article <v1p6hr$2btq7$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> 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.)
>
> Nope. Sorry.

I read that as "in Bash it's not the case". - Can't tell; I can just
say that what LDO was claiming for Bash at least is the behavior for
Ksh. (You are not arguing that Ksh would behave differently, do you?)

Janis

In article <v1qr6l$2qsv6$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>>>> 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.)
>>
>> Nope. Sorry.
>
>I read that as "in Bash it's not the case". - Can't tell; I can just
>say that what LDO was claiming for Bash at least is the behavior for
>Ksh. (You are not arguing that Ksh would behave differently, do you?)

You said that it does the right thing in ksh (*). LDO claimed
(incorrectly) that it does the right thing in bash. You then claimed that
it does the same thing in ksh as in bash, which is, clearly, incorrect.
Hence my Nope, Sorry.

(*) I have, just now, verified that it does the right thing in ksh - that
is, whatever version of ksh was laying around on this system for me to test
with.

P.S. I have also verified that, as noted by Christian, it does the wrong
thing in tcsh as well. I have not (yet) verified his statement about
things changing (in tcsh) when you have more than 9 background jobs...

--
On the subject of racism being depicted in the media, the far right and the far left have
met up in agreement (sort of like how plus infinity meets up with minus infinity).
The far left doesn't want it, because they are afraid it will make people racist.
The far right doesn't want it, because they are afraid it will make people feel bad about being racist.

On Sun, 12 May 2024 09:47:16 -0000 (UTC), Christian Weisgerber wrote:

> On 2024-05-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>> Job numbers are reused after it has notified you of termination of the
>> previous job. At least in Bash.
>
> Demonstrably false:

Works for me:

ldo@theon:~> sleep 10 &
[1] 1094669
ldo@theon:~> sleep 1 &
[2] 1094670
ldo@theon:~>
[2]+ Done sleep 1
ldo@theon:~> sleep 1 &
[2] 1094671

On 12.05.2024 18:51, Kenny McCormack wrote:
> In article <v1qr6l$2qsv6$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>>>>> 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.)
>>>
>>> Nope. Sorry.
>>
>> I read that as "in Bash it's not the case". - Can't tell; I can just
>> say that what LDO was claiming for Bash at least is the behavior for
>> Ksh. (You are not arguing that Ksh would behave differently, do you?)
>
> You said that it does the right thing in ksh (*). LDO claimed
> (incorrectly) that it does the right thing in bash. You then claimed that
> it does the same thing in ksh as in bash, which is, clearly, incorrect.
> Hence my Nope, Sorry.

I was assuming that LDO made a correct claim. But all I wanted to say
was that ksh is doing what LDO was describing. It wasn't my intention
to give the impression that I verified what Bash would do - Bash is
not the shell I am using.

>
> (*) I have, just now, verified that it does the right thing in ksh - that
> is, whatever version of ksh was laying around on this system for me to test
> with.

Not sure what the Right Thing would be. After all (for me) the choice
of %n is no more or less "right" than the choice of PIDs are; all I
need is certainty about validity in certain instances of time, not so
much whether or when the numbering is reused, restarted from 1.

Is there any practical problem I'm unaware about?

Janis

>
> [...]

On 2024-05-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>>> Job numbers are reused after it has notified you of termination of the
>>> previous job. At least in Bash.
>>
>> Demonstrably false:
>
> Works for me:
>
> ldo@theon:~> sleep 10 &
> [1] 1094669
> ldo@theon:~> sleep 1 &
> [2] 1094670
> ldo@theon:~>
> [2]+ Done sleep 1
> ldo@theon:~> sleep 1 &
> [2] 1094671

So if the highest numbered job terminates, that number is immediately
reused. Earlier ones are not.

It's a stack.

And again, that behavior is already present in csh.

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