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
