Hi Atte, Atte Peltomdki wrote on Thu, Feb 04, 2010 at 12:48:47PM +0200: > On Tue, Feb 02, 2010 at 09:32:43PM +0100, Ingo Schwarze wrote: >> Antti Harri wrote on Tue, Feb 02, 2010 at 07:31:57PM +0200:
>>> xargs' -L switch isn't working when using -0 flag. >> After checking POSIX.1 (2008), i conclude that our implementation and >> manual are correct in this respect. The -L option is concerned >> with "lines of arguments from standard input". ASCII nul characters >> do not delimit lines. [ snipped the Linux description of -print0, we agree on that ] > Using -0 for xargs simply means "Use \0 as otherwise \n or whitespace > are used". That's horribly imprecise. Rather, it means "interpret NUL and only NUL as the argument separator". I do not think that -0 should change the meaning of the term "line". NUL is not a line separator, and -0 does not make it one. The effect of find(1) -print0 is to put all names on the same line, separated by NUL characters, whereas find(1) -print puts each name on its own line. > This also has nothing to do with POSIX compliancy, since using -0 > in the first place breaks compliancy. No doubt, -0 is an _extension_ to POSIX and XPG (it doesn't break it, that makes a difference). When implementing the -0 extension, we must take care not to violate completely unrelated parts of the specification. In particular, i fail to see the point in giving the XPG standard options -I and -L non-standard meanings just because the non-standard -0 option happens to be in effect, too. >>> Tested also on OS X and Linux and they print two lines with -0. >> So you might wish to file bug reports with these operating systems. > I suggest OpenBSD rather change their -0 semantics to match those of > every other vendor which implement -0 in xargs. Nobody is discussing -0 semantics, it's -I and -L semantics that are at stake. And it looks like everyone else broke -L in their code. http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/xargs/xargs.c.diff?r1=1.55;r2=1.56 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/xargs/xargs.c?only_with_tag=MAIN#rev1.16 So, in 2005, FreeBSD introduced the same bug you report in Linux, and the commit message doesn't really give a clue what the point is: "so that 'xargs -0 -I []' will do something sensible (namely: treat then '\0' as the EOL character..." I don't really understand that: Philip already pointed out the difference between # XPG schwa...@rhea $ printf "a b" | xargs -L1 a b schwa...@rhea $ printf "a b" | xargs -n1 a b # extension schwa...@rhea $ printf "a\0b" | xargs -0 -L1 a b schwa...@rhea $ printf "a\0b" | xargs -0 -n1 a b where -n does in a standard way what other systems apparently abuse -L for. An analogous argument applies to -I: # extension schwa...@rhea $ printf "a b" | xargs -I % echo % x % a b x a b schwa...@rhea $ printf "a b" | xargs -n1 -I % echo % x % a x a b x b # extension schwa...@rhea $ printf "a\0b" | xargs -0 -I % echo % x % a b x a b schwa...@rhea $ printf "a\0b" | xargs -0 -n1 -I % echo % x % a x a b x b I admit that's all extending to XPG, since XPG does not require xargs -I to handle more than one input argument per input line, but handling it doesn't violate XPG and it's the traditional behaviour in FreeBSD since 2002 when -I was first ported from xMach. I call it *useful* that -I and -n1 -I do different things. It is a nuisance that on other systems, -0 -I apparently now does the same as -0 -n1 -I. Finally, in 2007, NetBSD copied the -L bug from FreeBSD. What a mess... :-( Yours, Ingo
