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

From: "David G. Pickett" <[email-masked]>
Date: Wed, 31 May 2023 19:17:15 +0000 (UTC)

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: [email-masked]
To: [email-masked]
Cc: [email-masked]; [email-masked]
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, [email-masked] 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 <[email-masked]> 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
>> [email-masked]
>>
>>
>>
>> &nbsp;
>>    
>
>
>
>