Tue 20 Jan 2004 02:15:50 PM UTC, original submission:
When the number of parameters to the xargs subcommand is limited by using -n <num>, xargs does not execute the subcommand until it has seen the end of the input stream OR num+1 arguments. This can result in unnecessary delays in execution where the command to be executed is known (it has seen num args) since it isn't actually executed until more arguments are discovered (or the input stream ends).
A (lame, but the best I could think of right now) example which assumes date outputs 6 words:
$ for i in 1 2 3 4; do date;date;sleep 3; done | xargs -n 6
Example output from this is shown below, with me inserting <delay 3 seconds> where the 3 second delays occur:
Tue Jan 20 14:09:35 GMT 2004
<delay 3 seconds>
Tue Jan 20 14:09:35 GMT 2004
Tue Jan 20 14:09:38 GMT 2004
<delay 3 seconds>
Tue Jan 20 14:09:38 GMT 2004
Tue Jan 20 14:09:41 GMT 2004
<delay 3 seconds>
Tue Jan 20 14:09:41 GMT 2004
Tue Jan 20 14:09:44 GMT 2004
<delay 3 seconds>
Tue Jan 20 14:09:44 GMT 2004
There is no apparent reason why the delays are occurring where they are - the second echo should be being executed as soon as 6 parameters are available, no? I don't think that the current behaviour is desirable (and it's a nuisance for my use of it).
I've tested this against findutils 4.1.7, but I've examined the latest (revision 1.17 of xargs/xargs.c) in CVS and it hasn't changed in this regard.
I think it would be fairly easy to fix this behaviour by inserting a check for reaching max_args near the end of the push_arg function after the new (non-NULL) argument has been added to the argument array, and calling do_exec immediately if the limit has been reached.
But I'm not certain, hence I'm not supplying a proposed patch at the moment. Does anybody else agree?
|