Re: CVS commit: src/usr.bin/pwait

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 4 Mar 2015 00:13:01 +0100
    From:        Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
    Message-ID:  <20150303231301.GB13722%britannica.bec.de@localhost>

  | It comes with a maintainance price. Add something better a version later
  | and it is significantly harder to get rid of the once shiny toy.

Taken even part way towards its extreme, this says that nothing new can
ever be added until it is known to be perfect - information that cannot
be obtained until it is added and used.  When coupled with some requirement
that there be some degree of consensus amongst developers the whole thing
becomes impossible to ever achieve.

Just trust the developers to make reasonable choices - any that make a habit
of recklessness should simply be turfed out.

If a developer thinks something is reasonable, and needed, and worth adding,
then let it be added.   If someone else believes there is a better solution,
then allow the original to be modified/updated/replaced (ie: no ownership ego
on the first method) - hopefully before the new functionality becomes part of
a new release.

Of course, developers also need to assess the costs of making errors, and
seeking advice if they're not sure - that's part of avoiding becoming
reckless.  But not every change or addition warrants that.

For system calls (including ioctls etc) real care needs to be taken to
avoid adding backwards compatibility costs forever - for commands, this
is less important, as if a new method provides a mechanism to achieve the
same functionality as the command being replaced (eg: if some new command
were to do what pwait(1) offers - perhaps in a different way) then backwards
compatibility handling is trivial - just needs a small script to replace the
C command using the new tool to achieve the result however is to be done,
along with a man page addition telling people to migrate away.

On the change in question - I don't personally have any need for it in the
form it currently exists - but that's not any kind of argument against it.
On the other hand, what I do really need in this area, is the ability to
wait for any one of a set of processes to exit (and to tell me which one,
status is less important, as I'll get that when I do a regular wait anyway).

That is, I have scripts that start a number of processes, and as each
finishes, start a replacement (until the work is done).   Currently
that turns out to be hard (writing at sh level - it is trivial in C or
similar) as the "wait" builtin either waits for everything, or requires
knowledge of which process (or job) is to finish next.  If it were possible
to modify pwait to exit when any of the processes in its arg list exited
(and print which pid that was) it would make something that is currently
very difficult become much easier.

kre