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

[Jim Meyering]

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> wrote:
> 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

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

  grep() { local re='^grep: .*: binary file matches$'; env grep "$@"
2> >(tee  >(env grep -av "$re" 1>&2) | env grep -a "$re"); }