Re: Idea: jobs(1) -i to print only :%ID:s

[Steffen Nurpmeso]

Chet Ramey wrote in
 <7402031f-424c-4766-ba70-71771c9dc32b@case.edu>:
 |On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
 |> The "problem" with the current way bash is doing it is that bash's
 |> job handling does not recognize jobs die under the hood:
 |> 
 |>    $ jobs
 |>    [1]-  Stopped                 LESS= less -RIFe README
 |>    [2]+  Stopped                 LESS= less -RIFe TODO
 |>    $ kill $(jobs -p)
 |>    $
 |> 
 |> ^ nothing
 |> 
 |>    $ jobs
 |>    [1]-  Stopped                 LESS= less -RIFe README
 |>    [2]+  Stopped                 LESS= less -RIFe TODO
 |
 |Yes, the jobs are still stopped, and will remain stopped until they get
 |a SIGCONT. Do you think that kill, when given a pid argument, should look
 |up any job associated with that pid and send it a SIGCONT? Or should it
 |send a SIGCONT to the pid unconditionally? If so, what about other
 |processes in that job?

Hm coming from this other side is also an interesting thing, but
which i did not think about.  I mean .. "if the lookup is fast"
kill(1) could of course throw all of its arguments against the
list of tracked processes, not only %job specifications.

(Having said that i am personally still hoping for a shell syntax
extension that closes the race condition of PID reuse against
kill(1), in that if i "kill -TERM ID" where ID is known to be
a monitored process, but which has terminated, the shell will
reject doing the kill as such.  Also the "kill -0 && kill -X" gap
is a race in itself.  But that is of course a different topic.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)