Things you (probably) didn't know about xargs

Developing some proficiency with commands such as find, xargs, sed, grep, etc. is where you can really gain productivity. There are studies showing that the perception that the command line is more efficient than a GUI is false; the GUI is actually faster. This may be true for relatively simple operations such as moving, copying, or deleting files, but by involving find, xargs, and a few pipes you can quickly accomplish operations that would be either very tedious or flatly impossible in most GUI file "explorers".

You can skip the pipe by using find's '-exec' option. It will save you the pipe.<p>The example: "find . -name '* .py' | xargs grep 'import'" would become "find . -name '* .py' -exec grep -H 'import' {} \;".<p>You need to include the -H in grep to get the filename in which the match occurs.

I wonder why -print0 / -0 isn't the default, as it seems that <i>not</i> using those options is the wrong way to do it.<p>(Either that or why filenames can have spaces or LFs in them.)

Use GNU Parallel if you need to execute jobs in parallel (<a href="http://www.gnu.org/software/parallel/" rel="nofollow">http://www.gnu.org/software/parallel/</a>)

The best thing about Unix, and maybe the worst, is that you never stop learning about it. Nice article.

Never pipe `find` to `xargs rm -f`. All you need is a malicious empty file called / and you're screwed. That's why `find` has a -delete flag.

While not the point of the article, I was happy to learn about bash's {..} operator! I've always missed perl's .. in the shell.<p><pre><code> echo {1..100}</code></pre>

Note that the first three examples can also be written in a much shorter form if you use zsh:<p><pre><code> wc -l **/*.py rm **/*~ grep 'import' **/*.py </code></pre> I like zsh a lot for this small feature.

A few issues with this article. No, GNU xargs does not truncate the generated command. It will span multiple commands. Nor is it "-print 0" but "-print0" in find. And as mentioned in other comments, GNU parallel is much better for job parallelization.

One thing that have bitten me in the past is the fact that xargs always runs at least once, even if there are no input. By using the -r / --no-run-if-empty flag, xargs does not run the command if the input does not contain any nonblanks.

I was just trying to figure out how to change the position of the arguments yesterday. I figured it out (thanks, man), but discovered the OS X version (FreeBSD?) uses -I while certain GNU versions use -i. Lame.

On a slightly related note, am I the only one who finds the argument syntax for `find` to be inconsistent? Shouldn't it be `find --name "*.bar"` or even `find --name=foo.bar`?

The trace param to Xargs is nice too: You can check what will happen before doing something.

zsh and its zargs command can easily overcome many of the limitations of xargs noted in the article. They also make the use of the "find" command unnecessary.

<i>Recursively find all Emacs backup files and remove them</i> <i>find . -name '</i>~' | xargs rm*<p><i>Recursively find all Python files and search them for the word ‘import’</i> <i>find . -name '</i>.py' | xargs grep 'import'*<p>Hmm. I don't mean to be a tweak, but you don't need xargs to do either of those things. Just:<p>find . -name '<i>~' -delete<p>find . -name '</i>.py' | grep 'import'<p>Note: I can't figure out how to get an asterisk to show up, and don't have time to look it up.

for a long time I avoid xargs like the plague. much less error prone to user a bash loop or something....<p>but that parallelization parameter may win me back as it's cleaner than &#38; and global vars for counters....