The xargs utility was usually found only in System V-based
systems; BSD systems included an apply utility that provided
functionality similar to xargs -n number. The SVID lists xargs
as a software development extension. This volume of POSIX.1‐2017
does not share the view that it is used only for development, and
therefore it is not optional.
The classic application of the xargs utility is in conjunction
with the find utility to reduce the number of processes launched
by a simplistic use of the find -exec combination. The xargs
utility is also used to enforce an upper limit on memory required
to launch a process. With this basis in mind, this volume of
POSIX.1‐2017 selected only the minimal features required.
Although the 255 exit status is mostly an accident of historical
implementations, it allows a utility being used by xargs to tell
xargs to terminate if it knows no further invocations using the
current data stream shall succeed. Any non-zero exit status from
a utility falls into the 1‐125 range when xargs exits. There is
no statement of how the various non-zero utility exit status
codes are accumulated by xargs. The value could be the addition
of all codes, their highest value, the last one received, or a
single value such as 1. Since no algorithm is arguably better
than the others, and since many of the standard utilities say
little more (portably) than ``pass/fail'', no new algorithm was
invented.
Several other xargs options were removed because simple
alternatives already exist within this volume of POSIX.1‐2017.
For example, the -i replstr option can be just as efficiently
performed using a shell for loop. Since xargs calls an exec
function with each input line, the -i option does not usually
exploit the grouping capabilities of xargs.
The requirement that xargs never produces command lines such that
invocation of utility is within 2048 bytes of hitting the POSIX
exec {ARG_MAX} limitations is intended to guarantee that the
invoked utility has room to modify its environment variables and
command line arguments and still be able to invoke another
utility. Note that the minimum {ARG_MAX} allowed by the System
Interfaces volume of POSIX.1‐2017 is 4096 bytes and the minimum
value allowed by this volume of POSIX.1‐2017 is 2048 bytes;
therefore, the 2048 bytes difference seems reasonable. Note,
however, that xargs may never be able to invoke a utility if the
environment passed in to xargs comes close to using {ARG_MAX}
bytes.
The version of xargs required by this volume of POSIX.1‐2017 is
required to wait for the completion of the invoked command before
invoking another command. This was done because historical
scripts using xargs assumed sequential execution. Implementations
wanting to provide parallel operation of the invoked utilities
are encouraged to add an option enabling parallel invocation, but
should still wait for termination of all of the children before
xargs terminates normally.
The -e option was omitted from the ISO POSIX‐2:1993 standard in
the belief that the eofstr option-argument was recognized only
when it was on a line by itself and before quote and escape
processing were performed, and that the logical end-of-file
processing was only enabled if a -e option was specified. In that
case, a simple sed script could be used to duplicate the -e
functionality. Further investigation revealed that:
* The logical end-of-file string was checked for after quote
and escape processing, making a sed script that provided
equivalent functionality much more difficult to write.
* The default was to perform logical end-of-file processing
with an <underscore> as the logical end-of-file string.
To correct this misunderstanding, the -E eofstr option was
adopted from the X/Open Portability Guide. Users should note that
the description of the -E option matches historical documentation
of the -e option (which was not adopted because it did not
support the Utility Syntax Guidelines), by saying that if eofstr
is the null string, logical end-of-file processing is disabled.
Historical implementations of xargs actually did not disable
logical end-of-file processing; they treated a null argument
found in the input as a logical end-of-file string. (A null
string argument could be generated using single or double-quotes
('' or ""). Since this behavior was not documented historically,
it is considered to be a bug.
The -I, -L, and -n options are mutually-exclusive. Some
implementations use the last one specified if more than one is
given on a command line; other implementations treat combinations
of the options in different ways.
