Re: bug in zsh wait builtin - rhbz#1150541

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 23,  9:32am, Peter Stephenson wrote:
}
} On Tue, 21 Oct 2014 23:55:42 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} >  Is "kill" supposed to work the same way?
} 
} There's no indication kill needs to have this.  Presumably this is
} because for kill you don't need to have a sensible exit status, just a
} reasonable likelihood the job is dead (or wedged in some state where
} that signal doesn't work, but that's an entirely different problem).

My implied point was that both commands accept either job identifiers
(%3, %?sleep?) or PIDs and presumably should act the same way for the
same child process regardless of how it was identified; or else PIDs
are something entirely different than job identifiers and the rules
are different.  But for "wait" treat PIDs magically while "kill" does
not, seems inconsistent.
 
} > Note also that this is partly handled by the POSIX_JOBS option:
} > 
} >      When the option is set, it becomes possible to use the wait
} >      builtin to wait for the last job started in the background (as
} >      given by $!) even if that job has already exited.  This works even
} >      if the option is turned on temporarily around the use of the wait
} >      builtin.
} > 
} > I would say that any further change made for this should also be under
} > the auspices (so to speak) of POSIX_JOBS.
} 
} That would already cover the cases in the "bug" report, in fact.

I don't think it would, because the report starts two background jobs
and then waits for the one started first.  The current implementation
only allows the most recent $! to be waited for after it exits.

} I'm not really sure why we wouldn't just implement this particular
} feature generally, despite the current status.  Is there any reason why
} you'd *want* "wait" to give you an error (which isn't a particularly
} useful message) owing to a race condition you can't control?

There are a lot of error messages that a script probably doesn't want
but an interactive user might.  Why do you want "wait %3" to report
"%3: no such job"?  If nobody wants it, why did it take us 25 years
to figure that out?

Maybe there should just be an option to never remove job table entries
until "wait" is explicitly called (and MONITOR + NOTIFY constitutes
an implicit wait).  Then even $pipestatus could be updated at wait-time
for backgrounded pipelines.  (I'm not seriously suggesting that, just
running this train out to the last station.  Keeping job table entries
around would solve the storage problem, but job table entries get made
for things like brace expressions for which "wait" makes no sense, and
managing pipestatus is a bear we only recently wrestled.)

OK, I'm done making up odd metaphors now.  Carry on.