Hey.
Not sure whether this has been brought up before (at least a quick
search didn't reveal anything in the bug tracker or the archive).
xargs -0 still executes the command even when no terminating NUL has
been found in the (last) line.
As shown by e.g. the following script foo.sh:
#!/bin/sh
printf '/'
if [ -n "$1" ]; then
kill -9 "$$"
fi
printf 'tmp\000'
Which yields:
$ ./foo.sh | xargs -0 printf '»%s«\n'
»/tmp«
$ ./foo.sh kill | xargs -0 printf '»%s«\n'
»/«
This, of course, can lead to catastrophic behaviour if the command
that's piped into xargs is killed at the wrong time.
Just consider an example like:
$ ./foo.sh kill | xargs -0 rm -rf
I think the proper behaviour would be to do both,
- not include any non-terminated line (e.g. NUL or LF)
though I would say it could execute for all other, properly
terminated lines, that have been read up to that point
- perhaps, if a non-terminated line was found, exit with some special
exit status (see below)
This problem is even mentioned in the most recent 2024 edition of
POSIX:
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/xargs.html
> FUTURE DIRECTIONS
> A future version of this standard may require that, when the -0
> option is specified, if the standard input is not empty and does not
> end with a null byte, xargs ignores the trailing non-null bytes.
I'll ask at the WG, whether it wouldn't be better to give an error
instead of ignoreing it.
Cheers,
Chris.
