== Two _xargs_ gotchas that you may not know about I know, I've been harping on _xargs_ a bit lately. But this stuff is important because most people's vague intuitions about how _xargs_ behaves is actually wrong. If you're like most people, you probably vaguely think that _xargs_ operates on lines of input and the purpose of the GNU _-0_ extension to _xargs_ (and _find_ et al) is so that some joker putting a newline in a file name doesn't cause the world to blow up. Actually it's much worse than that. The simple way to put this is ~~_xargs_ doesn't operate on lines, it operates on words~~. Words are the same as lines only if your lines don't have any whitespace, backslashes, single quotes (_'_) or double quotes (_"_), all of which _xargs_ will interpret in various ways. Oh, and blank lines are neither errors nor empty arguments under normal circumstances, they are simply word-separating whitespace. In short, newlines are only the beginning of the things that nasty people can put in their filenames to give you heartburn. (Normally you don't see any of this because your input to _xargs_ is well formed and simple.) The other trap ([[as I alluded to XargsZeroArgsIssueII]]) is the portable behavior of _xargs_ if you don't give an explicit _-E_ argument. If you don't, some versions of _xargs_ will assume that a line with only an underscore (``_'') actually means the (logical) end of file and won't read any further input. It will probably surprise no one that Solaris 10 update 8 (that bastion of old times) behaves this way. Fortunately Linux, FreeBSD, and OpenBSD don't appear to do so. (One of the morals here is that sometimes GNU programs make important innovations, as I believe that _xargs -0_ and _find ... -print0_ came from GNU.)