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

[Marcello Perathoner]

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.




Regards

--
Marcello Perathoner