> Besides, xargs isn’t good at transferring special symbols, such as space or quotes. Well, no, not when you're piping ls into it. That's what --null (or -0) i

> Besides, xargs isn’t good at transferring special symbols, such as space or quotes. Well, no, not when you're piping ls into it. That's what --null (or -0) is for. (Use find instead.) The man page offers a similarly baffling argument: > xargs deals badly with special characters (such as space, ' and "). To see the problem try this: touch important_file touch 'not important_file' ls not* | xargs rm mkdir -p "My brother's 12\" records" ls | xargs rmdir Same problem as the article: piping in the output of ls into xargs. > You can specify -0 or -d "\n", but many input generators are not optimized for using NUL as separator but are optimized for newline as separator. I still don't see the argument: if the generator is "optimized for newline as a separator", then -d is what you need. But if your generator is outputting a list of file names (perhaps the most common case of xargs), then -0 is what you need. It is perhaps somewhat unfortunate that its use of whitespace (and bash's use) make it so easy to write subtly incorrect programs; this is perhaps why there's such common advice to use Python, or anything not Bash. But the argument above leads me to think that `ls | parallels` would somehow work, which it cannot, for the very reasons we must use xargs -0. I suspect this is a long way about saying "we have (somewhat more, but still not quite) sane defaults". The correct command has always been `find . not* -print0 | xargs -0 ~/code/random/args.py`. Anything else is subject to weird corner cases of failure. It's a sad state of affairs really, and I'd love to change it. If you're just pounding out a command on the command line, you can usually ignore those corner cases, as you probably mentally know whether `ls not*` is going to cause issues or not; if you're writing a script for general use, then it's only a matter of time until it fails in interesting ways.