STANDARD INPUT

The standard input shall be a text file. The results are unspecified if an end-offile condition is detected immediately following an escaped <newline>.

INPUT FILES

None.

ENVIRONMENT VARIABLES

The following environment variables shall affect the execution of xargs:

LANG

This variable shall determine the locale to use for the locale categories when both LC_ALL and the corresponding environment variable (beginning with LC_ ) do not specify a locale. See 2.6.

LC_ALL

This variable shall determine the locale to be used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

LC_CTYPE

This variable shall determine the locale for the interpretation of sequences of bytes of text data as characters (e.g., single- versus multibyte characters in arguments and input files).

LC_MESSAGES

This variable shall determine the language in which messages should be written.

ASYNCHRONOUS EVENTS

Default.

STANDARD OUTPUT

None.

STANDARD ERROR

Used for diagnostic messages and the −t option. If the −t option is specified, the utility and its constructed argument list shall be written to standard error, as it will be invoked, prior to invocation.

OUTPUT FILES

None.

EXAMPLES

The xargs utility is usually found only in System V-based systems; BSD systems provide an apply utility that provides functionality similar to xargs −n number. The SVID lists xargs as a software development extension; POSIX. 2 does not share the view that it is used only for development, and therefore it is not optional. Note that input is parsed as lines and <blank>s separate arguments. If xargs is used to bundle output of commands like find dir -print or ls into commands to be executed, unexpected results are likely if any file names contain any <blank>s or <newline>s. This can be fixed by using find to call a script that converts each file found into a quoted string that is then piped to xargs. Note that the quoting rules used by xargs are not the same as in the shell. They were not made consistent here because existing applications depend on the current rules and the shell syntax is not fully compatible with it. An easy rule that can be used to transform any string into a quoted form that xargs will interpret correctly is to precede each character in the string with a backslash.

The following command will combine the output of the parenthesized commands onto one line, which is then written to the end of file log: (logname; date; printf "%s\n" "$0 $∗") | xargs >>log The following command will invoke diff with successive pairs of arguments originally typed as command line arguments (assuming there are no embedded <blank>s in the elements of the original argument list): printf "%s\n" "$∗" | xargs -n 2 -x diff On implementations with a large value for ARG_MAX, xargs may produce command lines longer than LINE_MAX. For invocation of utilities, this is not a problem. If xargs is being used to create a text file, users should explicitly set the maximum command line length with the −s option.

HISTORY OF DECISIONS MADE

The list of options has been scaled down extensively. As it had stood, the xargs utility did not exhibit an economy of powerful, modular, or extensible functionality. 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, POSIX. 2 selected only the minimal features required. The −n number option was classically used to evoke a utility using pairs of operands, yet the general case has problems when utility spawns child processes of its own. The xargs utility can sap resources from these children, especially those sharing the parent’s environment. The command, env, nohup, and xargs utilities have been specified to use exit code 127 if an error occurs so that applications can distinguish ‘‘failure to find a utility’’ from ‘‘invoked utility exited with an error indication.’’ The value 127 was chosen because it is not commonly used for other meanings; most utilities use small values for ‘‘normal error conditions’’ and the values above 128 can be confused with termination due to receipt of a signal. The value 126 was chosen in a similar manner to indicate that the utility could be found, but not invoked. Some scripts produce meaningful error messages differentiating the 126 and 127 cases. The distinction between exit codes 126 and 127 is based on KornShell practice that uses 127 when all attempts to exec the utility fail with ENOENT, and uses 126 when any attempt to exec the utility fails for any other reason.

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 will succeed. Any nonzero exit status from a utility will fall into the 1−125 range when xargs exits. There is no statement of how the various nonzero 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 POSIX. 2 standard utilities say little more

(portably) than ‘‘pass/fail,’’ no new algorithm was invented.

Several other xargs options were withdrawn because simple alternatives already exist within the standard. For example, the −eeofstr option has a sed work around. The −ireplstr option can be just as efficiently performed using a shell for loop. Since xargs will exec(3) with each input line, the −i option will usually not exploit xarg’s grouping capabilities. The −s option was reinstated since many of the balloters on Draft 8 felt that it was preferable to the −r option invented for that draft that required the implementation to use ARG_MAX − size bytes for command lines. The requirement that xargs never produce command lines such that invocation of utility is within 2048 bytes of hitting the POSIX. 1 {8} exec ARG_MAX limitations is intended to guarantee that the invoked utility has a little bit of 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 POSIX. 1 {8} is 4096 and the minimum value allowed by POSIX. 2 is 2048; therefore, the 2048-byte 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 POSIX. 2 is required to wait for the completion of the invoked command before invoking another command. This was done because existing 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.

Section 5: User Portability Utilities Option

Editor’s Note: This empty section is placeholder for a future revision (the User Portability Extension, P1003. 2a) to contain descriptions of utilities that are suitable for user portability on asynchronous character terminals. P1003. 2a is currently balloting within the IEEE. Contact the IEEE Standards Office to obtain a copy of the latest draft.

User Portability Utilities Option 685

Section 6: Software Development Utilities Option

This section describes utilities used for the development of applications, including compilation or translation of source code, the creation and maintenance of library archives, and the maintenance of groups of interdependent programs. The utilities described in this section may be provided by the conforming system; however, any system claiming conformance to the Software Development Utilities Option shall provide all of the utilities described here.