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.

Reply via email to