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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)