On Friday 21 May 2010 22:11:49 cov...@ccs.covici.com wrote: > Daniel D Jones <ddjo...@riddlemaster.org> wrote: > > Running the command: > > > > find -name *.ext | xargs -0 rm > > > > I get the result: > > > > rm: cannot remove `Long File Name One.ext\nLong File Name Two.ext\nLong > > File Name Three.ext\n': File name too long. > > > > (The actual list is much longer than this, of course, or I wouldn't be > > using xargs.) For some reason, the \n isn't being recognized as a > > separator but rather as a part of a single long file name. Don't think > > $IFS would affect a command like rm but it doesn't appear to be the > > issue: > > > > ddjo...@merlin ~ $ set | grep IFS > > IFS=$' \t\n' > > > > I don't see any other ser variable which looks like a likely candidate to > > cause the behavior. Anyone have a clue what's going on? > > Why do you have -0 -- this replaces the \n's with a null character -- is > that what you want?
Not exactly. It doesn't replace anything. It tells xargs to look for a null to separate fields and to ignore the normal field separation characters. This is required if you have spaces in the field name, otherwise xargs sees the spaces as a field separator. xargs was doing exactly what I told it to do. Unfortunately, I didn't read the man pages and was relying on some poorly written web pages which indicated that -0 told xargs to skip spaces but didn't mention that it also told it to ignore \n. The solution, as Patrick Holthaus pointed out, was to use the -print0 argument with find, which instructs find to use the null character as a field separator in its output. -- "The road of excess leads to the palace of wisdom." - William Blake
