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
2773414454@qq.com



 




------------------ 原始邮件 ------------------
发件人:                                                                                                                        "Jim Meyering"                                                                                    <jim@meyering.net&gt;;
发送时间:&nbsp;2023年5月30日(星期二) 凌晨1:55
收件人:&nbsp;"2773414454"<2773414454@qq.com&gt;;
抄送:&nbsp;"63780"<63780@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 PM 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"); }