>#!/usr/bin/env execlineb
>background { sleep 3 }
># wait on init; clearly not our child
>wait { 1 }
The short answer is that waiting on a pid that isn't a child of yours
is a programming error and the wait command has undefined behaviour in
this case. This is a cop-out, because execline is not C, and UB should
not happen, but it's genuinely a case I haven't considered. ^^"
The longer answer is that POSIX makes it incredibly difficult
to be fancy with waiting on processes. As long as you are waiting on
*one* process, or on *any* process, and that you want a response *now*
or are willing to *wait for as long as it takes* for a process to exit,
you can do it without trouble; but anything more complex than that,
such as waiting for *a set of* processes, or having a *timeout*, becomes
convoluted, sometimes excessively so.
Add to that the fact that execline's wait command has to also support
the case where it's called without a block, and follow the specification
(
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/wait.html )
in this case, and you end up with way more code that should be necessary
for something that sounds so simple:
[ If you have not visited skarnet.org's cgit in the last week, hit
https://git.skarnet.org/cgit once before clicking the following URL,
else
you will get caught by my LLM blocker and won't be able to access the
site again ]
https://git.skarnet.org/cgit/execline/tree/src/execline/wait.c?h=v2.9.9.2
And as you have noticed, even with that much code, the behaviour is
arguably incorrect. wait should report an error, not "succeed" silently.
I did not code fully functional "waitpids" primitives in skalibs
because
I did not think I'd need them: in C code, when you correctly track your
children, you can get by with the POSIX primitives and do not need
perfect
reporting in case of user error. But execline's wait command is an
exception, and that strictly speaking, the way it is currently
implemented
is insufficient. I'll see what I can do for the next release.
--
Laurent
Received on Mon Aug 31 2026 - 19:27:52 CEST