xargs is smart enough to deal with that. If the argument list would exceed certain limits (may depend on the system and the build to xargs, for some versions of xargs, limits can be set as parameters), as many copies of the program will be fired up as necessary. Limits exist on the number of arguments, and the total length of the arguments.

I remembered working on a Sun some time ago where a pipe with xargs gave problems with too many arguments - but I might have dreamt it.

OT: I'm quite happy of my wrong answer. It taught me that I had wrong expectations about xargs, and that it will work fine in my Linux box. And others will possibly benefit :)

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

I remembered working on a Sun some time ago where a pipe with xargs gave problems with too many arguments - but I might have dreamt it.

If so, then it would be a bug, as that would mean its xargs would not be POSIX compliant. I can't recall ever run into this problem using Solaris (but that doesn't prove anything - my memory isn't perfect). Here's the relevant quote from the POSIX docs:

The generated command line length shall be the sum of the size in byte
+s of the utility name and
each argument treated as strings, including a null byte terminator for
+ each of these strings. The
xargs utility shall limit the command line length such that when the c
+ommand line is invoked,
the combined argument and environment lists (see the exec family of fu
+nctions in the System
Interfaces volume of IEEE Std 1003.1-2001) shall not exceed {ARG_MAX}-
+2 048 bytes. Within
this constraint, if neither the -n nor the -s option is specified, the
+ default command line length
shall be at least {LINE_MAX}.
[download]

Perl --((8:>*

Edited by planetscape - replaced pre with code tags