[BusyBox] xargs patch again

[Stewart Brodie]

[c&p from archive - no individual attributions available - sorry - but it's
me & vodz]

> > > > Please find attached a patch for findutils/xargs.c to fix the
> > > > behaviour of the -n option to be more like the version in GNU
> > > > findutils.

> > > Hmm. I reanalised findutils-1.4.7. xargs utility from this package not
> > > analise max_chars execeed from reading process. I think, may be
> > > rewrite logic: counting max_chars form process_stdin() to counting
> > > max_args. This not added size vs your patch. Let me know what you
> > > think Stewart.

> > I think it would be a mistake to not count characters.  That counting
> > must have been in there for a purpose - presumably to allow you to avoid
> > some system limit on some systems.

> The max_chars limit checked before execute command, but not from reading
> processing in findutils-1.4.7 xargs. For example your test: "(date;
> sllep2;) ..." full readed with all sleeping and after only send "out limit
> max chars ... bal-bla".

Sorry, I don't understand.  I've just tried a Linux box with
findutils-1.4.7-4 RPM installed on it (was using 1.4.6 earlier) and seen no
difference in behaviour.  I've made the test slightly better (this still
assumes you get 6 words of output from the date command):

$ for i in 1 2 3 4 5; do date; date; sleep 3; done | xargs -n 6 echo

All three implementations of xargs produce the same output - the problem is
its lack of timeliness.  busybox's xargs is worst, GNU's is much better,
busybox's + my patch is best as it produces the ideal obvious behaviour,
specifically, that the command prints two identical dates, waits 3 seconds,
prints two more identical dates, waits 3 seconds etc.

GNU findutils shows one date immediately, then after the first sleep, two
different dates (the second one from the first loop iteration, the first one
from the second loop iteration), then sleeps 3 seconds, then two more
different dates (second from the second loop iteration, first from the third
iteration), etc.  This happens because it is waiting for a 7th parameter to
start or the input stream to end before committing to executing the echo
command.  This behaviour is faulty, in my opinion, but is often good enough
for most uses (typically for using the the output of 'find') but not good
enough for my use of it, which is annoying.

busybox's xargs doesn't print anything at all until the 5th sleep has been
completed, at which point you get the same overall output as the GNU
version, but it all comes in one lump after the total 15 seconds delay.
Technically, this is not faulty either - but it is highly undesirable and
completely useless for me.

busybox's xargs with my very small patch shows two identical dates, waits 3
seconds, shows 2 more identical dates, waits 3 seconds etc.  i.e. it *does*
execute the command when it reaches the argument limit without waiting to
see if this is the last time it's going to have to execute the command.

This is nothing to do with the maximum command line length limit that is
being monitored by max_chars.  The two measurements are independent and both
must be there.  It *must* be monitored too and as it can override the
max_args parameter if it's trying to avoid overflowing maximum command line
length (in characters).

-- 
Stewart Brodie