bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xargs: doesn't fail on missing terminator (which may have severe con


From: Bernhard Voelker
Subject: Re: xargs: doesn't fail on missing terminator (which may have severe consequences)
Date: Fri, 13 Dec 2024 23:05:29 +0100
User-agent: Mozilla Thunderbird

Hi Christoph,

On 12/12/24 4:17 PM, Christoph Anton Mitterer wrote:
So I'd still ask you to consider whether GNU's xargs can be modified
accordingly (and not just in some POSIXLY_CORRECT mode), as any other
behaviour seems truly dangerous to me.

I never saw a practical example why it would be dangerous.
Usually a data producer is buffered, and therefore atomically
outputting entries in a consistent way.
Is there proof from the wild that there was data loss?

Second, my main point, is that I believe that there is confusion
about what -0, --null stands for.
The usage output clarifies:

  -0, --null                   items are separated by a null, not whitespace;
                                 disables quote and backslash processing and
                                 logical EOF processing

The crucial word is "separate" which means it is something in between 2 entries:
   entry1  <separator> entry2
It is and was never a "terminator", i.e., something acknowledging that the 
previous
entry is committed.
  entry1 <terminator>
Consequently, the logical EOF processing is not neccessary and therefore
disabled, as stated above.

Third, a change like this one seems a tough one, because tons of scripts and 
users
rely on existing behavior.

Finally, xargs(1) is not alone: there are several tools in the same boat which
have an option to treat input separated/terminated by '\0', and which usually
accept regular newline or whitespace-separated input.
The latter usually mandates to have a terminating newline at least, because 
POSIX
says that text files have to end on a newline; otherwise they'd be be treated
as binary files.
How about those?

After all, at least #3 (known behavior) can strike back quite hard.
Therefore I suggest thinking well through all the possible cases, and their
pros and cons.
At least the current status quo is documented for now:
  "disables ... EOF processing".

Have a nice day,
Berny



reply via email to

[Prev in Thread] Current Thread [Next in Thread]