[Top][All Lists]

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

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

From: Paul Eggert
Subject: bug#22838: New 'Binary file' detection considered harmful
Date: Mon, 29 Feb 2016 15:35:19 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 02/29/2016 12:34 PM, Marcello Perathoner wrote:
On 02/29/2016 08:29 PM, Paul Eggert wrote:

They would 'blast' their terminals without grep too.

Sure, but in practice it's common for users to do something like this:

grep -r getaddrinfo_a *

I just now did this in my working copy of the GNU Emacs source code. If -a were the default, I would see 13874778 bytes on my screen, the vast majority of which would be useless or even harmful. As grep stands now, I see just 5480 bytes and they're mostly useful.

I was lucky in that I noticed that a 17GB tar file could not be a complete backup of a 500GB drive.

Yes, you were lucky there. But you were unlucky in that your backup software invoked grep without worrying about file name validity. Suppose a file name contained a newline? Your backups could be toast.

At least ... make the new behaviour optional.

It is optional; we merely disagree about the option's default value.

Since 2.21 I will now have to always specify -a or LC_ALL=C when
grepping my files.

I suggest using -a. LC_ALL=C won't work the way that you want on platforms where the C locale is UTF-8, or is pure ASCII. For example, on Fedora 23 or RHEL 7 with grep 2.23 we have:

$ printf '\200\n' | LC_ALL=C grep .
Binary file (standard input) matches

This is because the C locale is pure ASCII on these platforms, i.e., '\200' is not a valid character the way it is with traditional Unix. I don't know why Red Hat made that change.

reply via email to

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