I concur with Arnold: stdout/FD1 is for the data stream, stderr/FD2 is for errors and similar user communication outside the data stream. Finding a file, binary or otherside, should get it reported the same way. As grep was a *VERY* mature product, such a strange behavior should not have been introduced to it, especially breaking a past behavior.
-----Original Message----- From: g...@tlinx.org To: arn...@skeeve.com Cc: 2773414...@qq.com; 63...@debbugs.gnu.org Sent: Tue, May 30, 2023 5:01 pm Subject: bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr On 2023/05/28 23:51, arn...@skeeve.com wrote: > There is no real need to make such a change, given that it's really > easy to handle at the shell level: > >    ... | grep '...' 2>&1 | ... > ----   But why should the user have to worry work around a bug in grep? Why is finding the desired text in a binary file not a "positive finding" as it is in a text file? The point of the grep is to find the regex in matching files -- there is no differentiation between text and binary files in the concept of searching for a string in all files. This gets especially hairy when various utilities (gnu, et al.) classify ill-formatted text files as 'binary' because they don't fit some definition of a text file. Examples: * A "text" file that has a NUL byte terminating some paragraph  in the file can easily be taken as a binary file. * An "mbox" file may be classified as 'binary' due to mixed encodings  in incoming emails. * absence of a "eol" at the end of a file can force classification  of the file as binary -- only allowing the file to be written w/o the " eol" if the file is marked as binary. * The presence of a BOM at the beginning of a file might force a non-unicode  util to classify the file as binary. There are too many cases where someone would expect grep to display a positive for a file, where now, such a positive would only be noted on stderr. Noting a match (which is what grep should do), shouldn't be considered an error that is only output on stderr. Matches for files that are scanned with the appropriate options (assuming binary files are not skipped), should be displayed on stdout. This has been the case in the past and shouldn't be changed on some whim. Saying the user should work around a basic change in behavior for positive matches is "making the user wrong" and the opposite of "user-friendly". I also think this behavior change should be reverted to keep grep's positive findings consistently going to stdout. Linda Walsh OR some text editors force presence of a final "EOL" if the file is not explicitly marked as 'binary'.Some utils may classify a 'mbox' file as binary file due to mixed encodings of incoming emails. > HTH, > > Arnold > > "2773414454" via Bug reports for GNU grep <bug-grep@gnu.org> wrote: > > >> Hi ! >> >> >> 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? >> >> >> >> >> 2773414454 >> 2773414...@qq.com >> >> >> >> >>  > > > >Â
