Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell
Subject: Re: ksh - issue with (non-existing) jobs
Date: Sun, 26 Jan 2025 13:13:37 +0100
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <vn58ti$3o8mi$1@dont-email.me>
References: <vn2v1c$2s2ce$1@dont-email.me> <vn3u8a$35e2n$8@dont-email.me>
 <vn3vdk$3686j$1@dont-email.me> <vn45ut$37klv$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 26 Jan 2025 13:13:40 +0100 (CET)
Injection-Info: dont-email.me; posting-host="106eded911a07ff496ae75b441dde821";
	logging-data="3941074"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+k8qos24Oojot4oKxujb05"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:vXRUs9NWrNR2UemzoI624Tq+/H4=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vn45ut$37klv$6@dont-email.me>
Bytes: 2704

On 26.01.2025 03:17, Lawrence D'Oliveiro wrote:
> On Sun, 26 Jan 2025 01:25:22 +0100, Janis Papanagnou wrote:
> 
>> I'd guess, though, that it wouldn't have helped ...
> 
> Well, if you explicitly waited for a job it couldn’t find, then you would 
> be right. But given it is capable of waiting in general for any job to 
> terminate,

Not sure what you mean here.

You initiate jobs, say, by something like 'a_command &', the command
gets registered in a shell table. And at any time you can 'wait' for
it. The job information (with its actual execution state) is at least
as long in the job table until a <Enter> is hit, since the information
e.g. about termination must be created.

> it might take a different path through the code that is not 
> afflicted by the same state confusion.

Yes, that can of course be the case - I haven't inspected the source.

My guess is based just on the typical software architectures. Usually
you have one place to maintain the jobs, a [shell internal] job table,
and functions to check existence (registration) and get any required
attributes for any shell command that works with the registered shell
jobs. So if the respective shell commands see arguments like %1 they
would certainly look up those jobs and its attributes in that table
with that key. It's most likely that 'kill %1' and 'wait %1' would
both do such a table lookup, certainly _before_ they take the actions
on the identified job.

If you have another scenario in mind, please elaborate.

Janis