GNU bug report logs - #63780
Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr

Previous Next

Package: grep;

Reported by: "2773414454" <2773414454 <at> qq.com>

Date: Mon, 29 May 2023 04:56:02 UTC

Severity: normal

Tags: notabug

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "2773414454" <2773414454 <at> qq.com>
To: "Jim Meyering" <jim <at> meyering.net>
Cc: 63780 <63780 <at> debbugs.gnu.org>
Subject: bug#63780: ��� bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr
Date: Tue, 30 May 2023 09:01:18 +0800
[Message part 1 (text/plain, inline)]
&nbsp;&nbsp;&nbsp;&nbsp; I know my suggestion may seem silly, but in fact, I used grep3.4 related code for my project and provided it to the client, and recently provided the client with grep3.7 for an upgrade. After upgrade I found that the change from grep3.4 to grep3.5 caused my project to become invalid.

&nbsp;&nbsp;&nbsp; Since the project is running, my dilemma is that I can only modify the source code of grep3.7 to solve the customer problem, and I cannot adapt the grep command to the project. I tried to roll back the behavior to grep3.4. I find that there are batch use cases that fail. At least 3 grep binary matching open source patches need to be backed up, this is too much modification, and I am afraid of introducing new problems to affect the use of customers. So my original intention is to ask the community whether there is a better way to modify the grep3.7 source code. The binary matching behavior of grep3.7 and grep3.4 is consistent.
&nbsp;
&nbsp;&nbsp; &nbsp; I sincerely hope to get your help.



2773414454
2773414454 <at> qq.com



&nbsp;




------------------&nbsp;ԭʼʼ&nbsp;------------------
:                                                                                                                        "Jim Meyering"                                                                                    <jim <at> meyering.net&gt;;
ʱ:&nbsp;2023530(ڶ) 賿1:55
ռ:&nbsp;"2773414454"<2773414454 <at> qq.com&gt;;
:&nbsp;"63780"<63780 <at> debbugs.gnu.org&gt;;
:&nbsp;Re: bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr



tags 63780 notabug
close 63780

On Sun, May 28, 2023 at 9:5662PM 2773414454 via Bug reports for GNU
grep <bug-grep <at> gnu.org&gt; wrote:
&gt; Between grep3.4 and grep3.5, the grep message output type matching binary files (without the -a option added) changed from stdout to stderr. This results in the inability to pipe in matching messages, resulting in significant changes to the user experience. But this modification doesn't actually do much. Could you consider reversing this change?

Please read this excerpt from the NEWS and announcement for some of
the motivation for that change:

* Noteworthy changes in release 3.5 (2020-09-27) [stable]

** Changes in behavior

&nbsp; The message that a binary file matches is now sent to standard error
&nbsp; and the message has been reworded from "Binary file FOO matches" to
&nbsp; "grep: FOO: binary file matches", to avoid confusion with ordinary
&nbsp; output or when file names contain spaces and the like, and to be
&nbsp; more consistent with other diagnostics.&nbsp; For example, commands
&nbsp; like 'grep PATTERN FILE | wc' no longer add 1 to the count of
&nbsp; matching text lines due to the presence of the message.&nbsp; Like other
&nbsp; stderr messages, the message is now omitted if the --no-messages
&nbsp; (-s) option is given.

If you want to restore such diagnostics to stdout, you can invoke grep
through a bash/zsh function wrapper like this:
(it preserves all stderr, except that one diagnostic, which it
redirects to stdout):

&nbsp; grep() { local re='^grep: .*: binary file matches$'; env grep "$@"
2&gt; &gt;(tee&nbsp; &gt;(env grep -av "$re" 1&gt;&amp;2) | env grep -a "$re"); }
[Message part 2 (text/html, inline)]

This bug report was last modified 1 year and 357 days ago.

Previous Next


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