On Mon, 2024-12-09 at 21:00 +0100, Bernhard Voelker wrote: > The above test case can be simplified to the cases: > > $ printf 'hello' | xargs -0 printf "<%s>\n" > <hello> > > $ printf 'hello\0' | xargs -0 printf "<%s>\n" > <hello> > > $ printf 'hello\0world' | xargs -0 printf "<%s>\n" > <hello> > <world> > > $ printf 'hello\0world\0' | xargs -0 printf "<%s>\n" > <hello> > <world>
Sure, I merely tried to use an example which also shows how easy such a truncated record could happen by merely signal at the wrong time. In the above example one may easier confuse it with: "you send wrong data, your own fault" > > > 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. > > IMO the above, current bahavior is not that terribly bad, but rather > quite good and consistent. Which one, the one that's indicated as a future direction, or the one that actually allows (but I think recommends against) it for now and which is also xargs current behaviour? Cause the latter would IMO be terribly bad, just imagine you have something like; find / -type f -name '*.backup' -print0 | xargs -0 rm -f If by accident, you now get only the `/` from the actual `/foo/bar/baz.backup`, you'd remove everything. > A question in this context may rather be how xargs(1) should handle > empty, i.e., > Zero-length, entries: 'hello\0\0world'. I'd say that these should be simply empty arguments? Like in some_command 'hello' '' 'world' except that I'd not consider the world, as it's not properly terminated. Cheers, Chris.
