On Wed, Jan 31, 2024, 20:36 Robert Elz <k...@munnari.oz.au> wrote: > Date: Wed, 31 Jan 2024 11:35:57 -0500 > From: Chet Ramey <chet.ra...@case.edu> > Message-ID: <1e50aa99-8d53-4cdf-ba5e-6aaf3ccc6...@case.edu> > > | Not quite. `new' in this sense is the opposite of `anything in the > past' > | as Dale described it -- already notified and removed from the jobs > list. > > I guess the part about bash that I am not understanding here is how the > "already notified" works. To me there are just two ways for that, either > the user has done a "wait" which has collected that pid already (either > without -n, and no pid args, or with pid args and one of those is the pid > in question) or with -n and the pid in question was the one whose status > was returned, or the user/script did the jobs command (or jobs -l) and the > job in question was shown as completed. >
i say additional datastructure for the saving purpose .. Is there some other way? > > | Half the problem here is that bash aggressively marks dead jobs as > being > | notified in non-interactive shells without job control enabled, and > moves > | them out of the jobs table. > > That might be more than half the problem, it might be the entire problem. > > | If you use wait -n without arguments, you probably don't care, > > No you do, that just means any of the children ... the script could make > a list of all of them and supply that list, but if the list is just going > to contain all the existing children, why bother? (With -n - and not > exactly one pid arg, -p is generally going to be required, but that option > has no bearing on which process is selected, or might be, which is the > issue here). > > | but if you > | do, or if you use wait -n with pid/job arguments (which you've > presumably > | saved yourself) you're going to need slightly different semantics than > we > | have now to answer that reliably. And that will probably need a new > option. > > That's a pity, particularly since the current semantics don't seem to > be useful in general. Since the sole issue provoking that seems to be > the wait over and over policy, rather than "wait once, and remove > completely" > perhaps rather than a new, but different, -n like option, a better idea > would > be a "only once" option (ie: if the option (-r (remove) or -c (cleanup) or > -o > (once only)) is set, then when the wait with that option returns status or, > or waits until termination without returning status (in the not -n case, > with > no pid args, or many pid args) then the processes are completely deleted > from > everywhere in the shell. Using that option would make a changed -n safe > to use in loops. If you do that, also add an option (maybe the upper case > version of whatever is selected for that one, or just some other letter) to > mean "don't wait" (kind of like wait(2) WNOWAIT) - which in default bash > would > just be a no-op (except in posix mode, apparently - whereas the -[cor] > option > would be a no-op in posix mode). > > If you were to do that, other shells could add the same (except in probably > all of them, -[cor] would always be the default, and the other one would be > the one which changes behaviour). > > | And that's why I used `more': there are several differences, so which > | of those differences should we attempt to change? > > Just the one. > > | > The one change that should be made is > | > to allow wait -n to collect processes/jobs that have already > terminated. > | > | Yes, that's one of the things we're talking about. I don't have any > problem > | with it, but should it take a new option to change those semantics? > > Good, though I think some more thought should go into that. In another > thread you said (paraphrasing) correctly, that scripts should not be > relying upon bugs, and the current wait -n behaviour is a bug - that it > might have been intentionally coded that way doesn't make it any less so. > It isn't as if it was ever documented to work the way it does, or everyone > would have known about it already. > > | > Changing it to wait for all the listed pids > | It's never done that. > | We're not going to change the return value from wait. > > Good, I only mentioned those possibilities because your earlier > message was unclear about what "more like wait without -n" meant. > > | Yeah, but we're talking about bash here. It doesn't really matter what > | the Bourne shell did; there are likely plenty of scripts that assume > | the historical bash behavior. > > Really? Why? What's the point of collecting the status twice? > It can't change in the meantime can it, once a process has done exit(N) > its exit status should always be N, regardless of how often it is waited > upon. > > [Aside: this should be obvious, but when one is collecting status changes, > rather than just "terminated" status, then the pid isn't removed if it > returns a "stopped" or "continued" status.] > > | > I meant the distinction between processes > | > that the shell has already collected status for, and those for which > it > > | You're not the first to propose something like that, but I'm not going > to > | be writing that code any time soon. > > Nor am I, if you go back to the message where I first mentioned it, > which I can't locate at the minute, I am fairly sure I said that while > it might help in this case, I doubt it is worth the effort. Or something > like that. > > Actually, found it eventually (this is quoting myself, earlier): > >> But as long as it is just a matter of cleaning up, and jobs works for > >> that, I don't currently see the need. > > | It is, in fact, true in the current implementation, as long as the pid > | is in the jobs list. > > That caveat is the problem. > > | It's always been true. If there is a job marked > | (internally, if you must) as dead for which the user has not yet > received > | notification, wait -n returns it and marks it as notified (and deletes > | it from the jobs list). > > That part is good. > > | Yes, that's one of the things we're talking about: whether wait -n > should > | consider pids/jobs *not* in the jobs list, the way wait without -n > does. > | That's about the only thing we're talking about changing here so far. > > Maybe a better discussion, and potential change, would be to whatever > other that the use of the wait, or jobs, commands can result in a job > moving out of the jobs list. If there were nothing other than those, > (and jobs list overflow or similar) then we'd be fine, and it seems to > me now, no change to the -n operation would be needed. > > | That hasn't actually been true with bash running in default mode for a > | very long time now. Bash has allowed multiple waits for the same pid > for > | many years, whether or not you or I think it's a good idea or the > correct > | semantics. Even if it was an accident of the implementation, and maybe > you > | could say it was, we are stuck with it. > > Which is why I suggested an option (just above) to turn that misfeature > off. > Even better perhaps might be a bash shopt. > > | It's ok, we got one. > > A kind of unlikely one. > > kre > > >
