bug#63780: »Ø¸´£º bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr

[2773414454]

     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.

    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.
 
     I sincerely hope to get your help.



2773414454
2773414...@qq.com



 




------------------ ???????? ------------------
??????:                                                                         
                                               "Jim Meyering"                   
                                                                 
<j...@meyering.net&gt;;
????????:&nbsp;2023??5??30??(??????) ????1:55
??????:&nbsp;"2773414454"<2773414...@qq.com&gt;;
????:&nbsp;"63780"<63...@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:56?6?2PM 2773414454 via Bug reports for GNU
grep <bug-grep@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"); 
}