GNU bug report logs - #22461
problem with "Binary file messages" in latest snapshot

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22461 in the body.
You can then email your comments to 22461 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: grep mailing list <bug-grep <at> gnu.org>
Subject: problem with "Binary file messages" in latest snapshot
Date: Mon, 25 Jan 2016 01:19:42 -0800

I ran into this problem when using 'grep' to search through GNU Emacs installed 
files. Here's how to reproduce the problem:

$ (echo xxx && yes yyy | sed 100000q && printf '\0') >big
$ grep xxx big
xxx
Binary file big matches

The last line should not be output. I'll look into fixing this.

Message #10 received at 22461-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 22461-done <at> debbugs.gnu.org
Subject: Re: problem with "Binary file messages" in latest snapshot
Date: Sun, 31 Jan 2016 23:31:18 -0800

[Message part 1 (text/plain, inline)]

I installed the attached patch, which should fix the bug, and am closing this.

[0001-Omit-excess-Binary-file-.-matches.patch (text/x-diff, attachment)]

Message #13 received at 22461 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 22461 <at> debbugs.gnu.org
Subject: Re: bug#22443: Subject: new snapshot available: grep-2.22.31-8b6a
Date: Mon, 1 Feb 2016 08:20:15 -0800

On Sun, Jan 31, 2016 at 11:30 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Jim Meyering wrote:
>>
>> I looked into it and do not see a way to fix it with reasonable cost.
>> When grep finds a NUL byte, it punts on the entire block.
>
>
> Hmm, I think of it differently. When grep finds a NUL it records that the
> file is binary but if no match has been found so far, it keeps looking for
> the first match, either in the block containing the NUL or in a later block.
> In this case grep stops reading the file only after finding a match, and it
> works correctly.
>
> The problem occurs if grep finds one or more text matches before the first
> NUL: it reports those matches, records the fact that it found them, then
> sees the NUL, then stops reading that file, and then the calling code
> notices that this was (1) a binary file that (2) contained matches, so
> outputs the "Binary file ... matches" message. This is wrong, because no
> binary data actually matched.
>
> When grep finds a NUL, it should record that the file is binary and then
> look for one more match after the NUL, then quit reading the file and report
> "Binary file ... matches" only if it found that one more match.
>
> The code is complicated by the fact that the file could also be binary
> because an output line contains an encoding error, something that's detected
> in a different part of the code.
>
> Argh, I'm taking too long to explain this. It's easier to fix than to
> explain. I installed a patch; what do you think?

Oh, I see, now. Nicely done. I noticed only now that I replied to you
off-list. Didn't mean to. So am adding the bug email in Cc, so your
explanation
is recorded there.

I added one more test case:
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=43f6246fe82f1

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.