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

[Marcello Perathoner]

On 02/29/2016 11:37 PM, Eric Blake wrote:
> On 02/29/2016 01:11 PM, Marcello Perathoner wrote:
>
> > > Yes, locale dependencies on standard behavior can be annoying.
> >
> > You assume that a user will only ever want to grep text files encoded in
> > the machine's locale. That is not so.
>
> You've been relying on undefined behavior, and it caught up with you.

(The backup2l author has been relying. I'm just a user of that package 
and I already filed a bug against backup2l too.)

You confuse 'undefined' with 'undocumented'.  The old behaviour was very 
well defined, even if it could turn out nasty.  It was defined by 
implementation: it was a de-facto standard.

OTOH it was nowhere documented that grepping non-locale files was 
considered marginal or illegal.

The old documentation explicitly stated:

"""
If  the  first  few  bytes  of  a file indicate that the file contains 
binary data, assume that the file is of type TYPE. By  default, TYPE  is 
 binary,  and  grep normally outputs either a one-line message saying 
that a binary file matches, or no message if there is no match.
"""
--- from an old man page

The new behaviour changes documented old behaviour.



Furthermore there's no need to fix the old bug in such a heavy-handed 
way. Less disrupting alternatives:

1) Make the new behaviour an opt-in.  Print a deprecation warning that 
gives people a chance to fix their scripts.  After a while make the new 
behaviour the default.

2) If you just output

   binary line 42 in file x matches

and continue regular output after the next newline, the breakage would 
be much more confined.

3) Fail in the old documented way of printing only the error message 
instead of introducing a new mode of failure that looks like success and 
loses the error message in the noise.

4) Don't implement this change between minor releases. A breaking change 
deserves a major release.



Regards

--
Marcello Perathoner