[to3m]

xargs is worse than find, I'd say, on account of its useless default mode of operation.

If it accepted newline-delimited input, it would cater for every non-pathological case, rather than (as it does now) failing miserably on many reasonable file names. (Of course, you have xargs -0 - but not all tools output appropriate data. And it accepts shell-style quoting - but do we really want that contagion to spread?)

The bizarre thing is that except for oddities like `echo * | xargs', every tool I've ever met that outputs lists of file names outputs them with newline as the separator. And any that currently don't, would be better off doing that, anyway, I'd argue - since most Unix tools are line-oriented.

[Sodel]

Agreed. Posix xargs is bafflingly inane. GNU xargs, at least, supports `xargs -d '\n'` to regain some line-oriented sanity. I prefer to use GNU parallel these days, though, since it's line-oriented by default and a bit more ergonomic.

[jschwartzi]

xargs is very powerful when you want to run one command with many arguments, but each argument is newline-delimited. That's basically all I use it for, and it saves me a lot of looping and subshell creation.

For example, when purging backups from Mercurial after a revert:

find . -name *.orig | xargs rm

[icebraining]

But that's exactly it - if any of the filenames have spaces, that will fail, since xargs will try to delete each part separately. From the man page:

Because Unix filenames can contain blanks and newlines, this default behaviour is often problematic; filenames containing blanks and/or newlines are incorrectly processed by xargs.

[johnwfinigan]

Excluding filenames containing newlines, I wonder how many weird corner cases this would reveal:

    ls | tr '\n' '\0' | xargs -0 rm

I've been annoyed by ls and xargs not playing together here and there, but the above only just occurred to me. Not sure if it's a good idea yet or not!

[zb]

find . -name '*.orig' -delete