Apologies for a typo:
With the discussed change this would return 44080: 1 in an endless loop.
1, not 0
On Tue, Jan 30, 2024 at 10:14 AM Steven Pelley wrote:
>
> > OK. Can you think of a use case that would break if wait -n looked at
> > terminated processes?
>
> Yes. I
> OK. Can you think of a use case that would break if wait -n looked at
> terminated processes?
Yes. If one were to start a number of bg jobs and repeatedly send the
list of pids to wait -n (probably redirecting stderr to /dev/null to
ignore messages about unknown jobs) today you'd process the jo
> > It does look in the table of saved exit statuses, returning 1.
>
> It doesn't. In this case, the code path it follows marks the job as dead
> but doesn't mark it as notified (since it exited normally), so it's still
> in the jobs list when `wait -n' is called, and available for returning.
> Tha
Thank you Chet for your thorough reply.
You make a few comments about differences in output (stderr for not
finding a job, notifications for jobs terminating) and in all cases I
believe you are correct. Let's assume job control is disabled.
> >
> > I expect the line ending (BUG) to indicate a re
handler but this could easily be a matter of chance timing and a red
herring.
Steve
On Wed, Jan 24, 2024 at 12:40 PM Steven Pelley wrote:
>
> > In the first case, if the subprocess N has terminated, its report is
> > still queued and "wait" retrieves it. In the seco
> In the first case, if the subprocess N has terminated, its report is
> still queued and "wait" retrieves it. In the second case, if the
> subprocess N has terminated, it doesn't exist and as the manual page
> says "If id specifies a non-existent process or job, the return status
> is 127."
>
> W
Hello,
I've encountered what I believe is a bug in bash's "wait -n". wait -n
fails to return for processes that terminate due to a signal prior to
calling wait -n. Instead, it returns 127 with an error that the
process id cannot be found. Calling wait (without -n) then
returns its exit code (e.
