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
