Xargs

xargs (short for "eXtended ARGuments" ) is a command on Unix and most Unix-like operating systems used to build and execute commands from standard input. It converts input from standard input into arguments to a command.
Some commands such as codice_1 and codice_2 can take input either as command-line arguments or from the standard input. However, others such as codice_3 and codice_4 can only take input as arguments, which is why xargs is necessary.
The command has also been ported to the IBM i operating system.
Examples.
One use case of the xargs command is to remove a list of files using the rm command. POSIX systems have an for the maximum total length of the command line, so the command may fail with an error message of "Argument list too long" (meaning that the exec system call's limit on the length of a command line was exceeded): rm /path/* or rm $(find /path -type f). (The latter invocation is incorrect, as it may expand globs in the output.)
This can be rewritten using the codice_5 command to break the list of arguments into sublists small enough to be acceptable:
find /path -type f -print | xargs rm
In the above example, the codice_6 utility feeds the input of codice_5 with a long list of file names. codice_5 then splits this list into sublists and calls codice_9 once for every sublist.
xargs can also be used to parallelize operations with the codice_10 argument to specify how many parallel processes should be used to execute the commands over the input argument lists. However, the output streams may not be synchronized. This can be overcome by using an codice_11 argument where possible, and then combining the results after processing. The following example queues 24 processes and waits on each to finish before launching another.
find /path -name '*.foo' | xargs -P 24 -I '{}' /cpu/bound/process '{}' -o '{}'.out
xargs often covers the same functionality as the command substitution feature of many shells, denoted by the backquote notation (`...` or $(...)). xargs is also a good companion for commands that output long lists of files such as codice_6, codice_13 and codice_1, but only if one uses codice_15 (or equivalently codice_16), since codice_5 without codice_15 deals badly with file names containing ', " and space. GNU Parallel is a similar tool that offers better compatibility with find, locate and grep when file names may contain ', ", and space (newline still requires codice_15).
Placement of arguments.
: single argument.
The xargs command offers options to insert the listed arguments at some position other than the end of the command line. The -I option to xargs takes a string that will be replaced with the supplied input before the command is executed. A common choice is %.
$ mkdir ~/backups
$ find /path -type f -name '*~' -print0 | xargs -0 -I % cp -a % ~/backups
The string to replace may appear multiple times in the command part. Using at all limits the number of lines used each time to one.
: any number.
Another way to achieve a similar effect is to use a shell as the launched command, and deal with the complexity in that shell, for example:
$ mkdir ~/backups
$ find /path -type f -name '*~' -print0 | xargs -0 sh -c 'for filename; do cp -a "$filename" ~/backups; done' sh
The word at the end of the line is for the POSIX shell to fill in for , the "executable name" part of the positional parameters (argv). If it weren't present, the name of the first matched file would be instead assigned to codice_20 and the file wouldn't be copied to codice_21. One can also use any other word to fill in that blank, for example.
Since accepts multiple files at once, one can also simply do the following:
$ find /path -type f -name '*~' -print0 | xargs -0 sh -c 'if [ $# -gt 0 ]; then cp -a "$@" ~/backup; fi' sh
This script runs with all the files given to it when there are any arguments passed. Doing so is more efficient since only one invocation of is done for each invocation of .
Separator problem.
Many Unix utilities are line-oriented. These may work with codice_5 as long as the lines do not contain codice_23, codice_24, or a space. Some of the Unix utilities can use NUL as record separator (e.g. Perl (requires codice_15 and codice_26 instead of codice_27), codice_13 (requires using codice_15), codice_6 (requires using codice_31), codice_1 (requires codice_33 or codice_34), codice_35 (requires using codice_33)). Using codice_15 for codice_5 deals with the problem, but many Unix utilities cannot use NUL as separator (e.g. codice_39, codice_40, codice_41, codice_4, codice_43, codice_44, codice_45, codice_46).
But often people forget this and assume codice_5 is also line-oriented, which is not the case (per default codice_5 separates on newlines and blanks within lines, substrings with blanks must be single- or double-quoted).
The separator problem is illustrated here:
touch important_file
touch 'not important_file'
mkdir -p '12" records'
find . -name not\* | tail -1 | xargs rm
find \! -name . -type d | tail -1 | xargs rmdir
Running the above will cause codice_49 to be removed but will remove neither the directory called codice_50, nor the file called codice_51.
The proper fix is to use the GNU-specific codice_31 option, but codice_40 (and other tools) do not support NUL-terminated strings:
find . -name not\* -print0 | xargs -0 rm
find \! -name . -type d -print0 | xargs -0 rmdir
When using the codice_31 option, entries are separated by a null character instead of an end-of-line. This is equivalent to the more verbose command:find . -name not\* | tr \\n \\0 | xargs -0 rm or shorter, by switching codice_5 to (non-POSIX) line-oriented mode with the codice_56 (delimiter) option: find . -name not\* | xargs -d '\n' rm
but in general using codice_15 with codice_31 should be preferred, since newlines in filenames are still a problem.
GNU codice_59 is an alternative to codice_5 that is designed to have the same options, but is line-oriented. Thus, using GNU Parallel instead, the above would work as expected.
For Unix environments where codice_5 does not support the codice_15 nor the option (e.g. Solaris, AIX), the POSIX standard states that one can simply backslash-escape every character:find . -name not\* | sed 's/\(.\)/\\\1/g' | xargs rm. Alternatively, one can avoid using xargs at all, either by using GNU parallel or using the functionality of .
Operating on a subset of arguments at a time.
One might be dealing with commands that can only accept one or maybe two arguments at a time. For example, the codice_63 command operates on two files at a time. The codice_64 option to codice_5 specifies how many arguments at a time to supply to the given command. The command will be invoked repeatedly until all input is exhausted. Note that on the last invocation one might get fewer than the desired number of arguments if there is insufficient input. Use codice_5 to break up the input into two arguments per line:
$ echo {0..9} | xargs -n 2
0 1
2 3
4 5
6 7
8 9
In addition to running based on a specified number of arguments at a time, one can also invoke a command for each line of input with the codice_67 option. One can use an arbitrary number of lines at a time, but one is most common. Here is how one might codice_63 every git commit against its parent.
$ git log --format="%H %P" | xargs -L 1 git diff
Encoding problem.
The argument separator processing of codice_5 is not the only problem with using the codice_5 program in its default mode. Most Unix tools which are often used to manipulate filenames (for example codice_43, codice_72, codice_35, etc.) are text processing tools. However, Unix path names are not really text. Consider a path name /aaa/bbb/ccc. The /aaa directory and its bbb subdirectory can in general be created by different users with different environments. That means these users could have a different locale setup, and that means that aaa and bbb do not even necessarily have to have the same character encoding. For example, aaa could be in UTF-8 and bbb in Shift JIS. As a result, an absolute path name in a Unix system may not be correctly processable as text under a single character encoding. Tools which rely on their input being text may fail on such strings.
One workaround for this problem is to run such tools in the C locale, which essentially processes the bytes of the input as-is. However, this will change the behavior of the tools in ways the user may not expect (for example, some of the user's expectations about case-folding behavior may not be met).