[Top][All Lists]

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

bug#22838: New 'Binary file' detection considered harmful

From: Marcello Perathoner
Subject: bug#22838: New 'Binary file' detection considered harmful
Date: Mon, 29 Feb 2016 21:34:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0

On 02/29/2016 08:29 PM, Paul Eggert wrote:
On 02/29/2016 09:14 AM, Marcello Perathoner wrote:
Keeping the old bug is far wiser than to fix it and introduce a new bug.

That depends on the bugs in question. The old bugs were pretty bad.

Copying faulty input to the output is a preferable failure mode

Again, we cannot satisfy everybody. There are reasonable complaints from
users if 'grep' blasts improperly-encoded data to their terminals, or
more generally if grep's improperly-encoded output trashes other
programs that read the output.

They would 'blast' their terminals without grep too. I don't see any grounds for a complaint like that. Grep is not a sanitizer.

 This is why grep has the -a option.  It
sounds like you need grep's -a option for your application, and it
should be easy to use -a.  It's not clear that -a should be the default.

I was lucky in that I noticed that a 17GB tar file could not be a complete backup of a 500GB drive. I was lucky because the now offending filename (the same filename that didn't bother grep for over 10 years) was early in the file list. If it had been late in the file list I wouldn't have noticed that a 400GB tar file was missing a few thousand files.

Other people may not be that lucky and they could get understandably angry at losing their data.

At least, if you must turn grep into a text file sanitizer, make the new behaviour optional. You can then tell people who complain about 'blasted' terminals to turn on that option, while other people would not blindly incur into the new bug.


Marcello Perathoner

reply via email to

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