Stephane Chazelas wrote, on 09 Jan 2023: > > > On page 3365 line 114593 section xargs (DESCRIPTION), > [...] > > If the <b>-0</b> option is specified, the application shall ensure that > > arguments in the standard input are separated by null bytes. > [...] > > Shouldn't that be "delimited" instead of "separated" above.
The existing text has: The application shall ensure that arguments in the standard input are separated by unquoted <blank> characters, unescaped <blank> characters, or <newline> characters. So I based the proposed new -0 text on that. I can see now that this was not quite right. > printf 'a\0' | xargs -0 printf '<%s>\n' > > outputs <a>, not <a> and <> for instance. Yes, also there is this difference to take into account: $ printf 'a\n\nb\n' | xargs printf '<%s>\n' <a> <b> $ printf 'a\0\0b\0' | xargs -0 printf '<%s>\n' <a> <> <b> > I would even go further and say that it's unspecified whether > > printf 'a\0b' | xargs -0 printf '<%s>\n' > > outputs <a> or <a> and <b>. > > All current implementations do the latter, but that's > potentially dangerous. That means for instance that in: > > find /var/tmp -name '*.tmp' -type d -prune -print0 | > xargs -0 rm -rf > > If find is killed (like with a SIGXCPU when it reaches some > resource limit) after it has output a block that happens to > end in the middle of /var/tmp/foo/bar.tmp at /var, you end up > removing the whole of /var. > > Leaving it unspecified would allow implementations to implement > a safer behaviour whereby only delimited records generate a > corresponding argument. I agree. I'll reopen the bug and propose new wording there. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England