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.