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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63780 in the body.
You can then email your comments to 63780 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "2773414454" <2773414454 <at> qq.com>
To: "bug-grep" <bug-grep <at> gnu.org>
Subject: Reversing the grep message output type matching binary files (without
 the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 08:54:07 +0800

[Message part 1 (text/plain, inline)]

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



&nbsp;

[Message part 2 (text/html, inline)]

Message #8 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: arnold <at> skeeve.com
To: 63780 <at> debbugs.gnu.org, 2773414454 <at> qq.com
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 00:51:32 -0600

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 | ...

HTH,

Arnold

"2773414454" via Bug reports for GNU grep <bug-grep <at> 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
> 2773414454 <at> qq.com
>
>
>
> &nbsp;

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul Jackson" <pj <at> usa.net>
To: bug-grep <at> gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 03:44:31 -0500

>> grep '...' 2>&1

But won't that send all error messages into the stdout stream,
not just the "binary file matches" messages?

-- 
                Paul Jackson
                pj <at> usa.net

Message #14 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 2773414454 <2773414454 <at> qq.com>
Cc: 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 10:55:18 -0700

tags 63780 notabug
close 63780

On Sun, May 28, 2023 at 9:56 PM 2773414454 via Bug reports for GNU
grep <bug-grep <at> 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"); }

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul Jackson" <pj <at> usa.net>
To: bug-grep <at> gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 17:37:24 -0500

That "2> >(...)" syntax forprocess substition off the explicitly specified file
descriptor 2 output surprised me.

Only now, thanks to this example, do I realize that this usage is implied
in the two zshmisc(1) REDIRECTION section sentences beginning with:

>> If one of the above is preceded by a digit  ...

and 

>> The various forms of process substitution ... are often used together with redirection ...

Once again, as I have known for nearly a half century, man pages are sometimes
written to only be understood by those who already know what they are reading..

-- 
                Paul Jackson
                pj <at> usa.net

Message #20 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: "2773414454" <2773414454 <at> qq.com>
To: "Jim Meyering" <jim <at> meyering.net>
Cc: 63780 <63780 <at> debbugs.gnu.org>
Subject: �ظ��� bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr
Date: Tue, 30 May 2023 09:01:18 +0800

[Message part 1 (text/plain, inline)]

     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 <at> qq.com



&nbsp;




------------------&nbsp;ԭʼ�ʼ�&nbsp;------------------
������:                                                                                                                        "Jim Meyering"                                                                                    <jim <at> meyering.net&gt;;
����ʱ��:&nbsp;2023��5��30��(���ڶ�) �賿1:55
�ռ���:&nbsp;"2773414454"<2773414454 <at> qq.com&gt;;
����:&nbsp;"63780"<63780 <at> 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 <at> 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"); }

[Message part 2 (text/html, inline)]

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul Jackson" <pj <at> usa.net>
To: bug-grep <at> gnu.org
Subject: Re: bug#63780: �ظ��� bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 20:13:46 -0500

>> So my original intention is to ask the community whether there is a better way to modify the grep3.7 source code. 

I doubt it makes sense to change (revert, in this case) grep's interface for all other users,
for the benefit of one user who has limited ways of adapting to the current interface.

Can you code a wrapper for grep, whether in bash/zsh shell or in C or similar, that is also
called "grep" and appears on the PATH before the "real" grep?  This wrapper could invoke
the "real" grep, fixup the one issue of concern here, that the "binary file matches" error
message might come out on the "wrong" (for your use case) file descriptor, and leave all
the other grep work to whatever the currently installed "real" grep does.

-- 
                Paul Jackson
                pj <at> usa.net

Message #26 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: Jeffrey Walton <noloader <at> gmail.com>
To: 2773414454 <2773414454 <at> qq.com>
Cc: 63780 <63780 <at> debbugs.gnu.org>
Subject: Re: bug#63780: �ظ��º bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 21:44:11 -0400

On Mon, May 29, 2023 at 9:02 PM 2773414454 via Bug reports for GNU
grep <bug-grep <at> gnu.org> wrote:
>
> &nbsp;&nbsp;&nbsp;&nbsp; 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.
>
> &nbsp;&nbsp;&nbsp; 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.

Maybe ack(1) could be a suitable replacement for you. ack(1) man page
at https://linux.die.net/man/1/ack .

Or, you could roll your own replacement with just the functionality you need.

Or, you could describe the problem you are trying to solve, rather
than trying to revert to grep 3.4. Someone may be able to help you
with it.

Jeff

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul Jackson" <pj <at> usa.net>
To: bug-grep <at> gnu.org
Subject: Re: bug#63780: �ظ��º bug#63780: Reversing the grep message output type matching binary files (without the -a option added) changed from stdout to stderr
Date: Mon, 29 May 2023 22:44:26 -0500

... or if you're really just looking for which files to backup, based on the contents of those files matching some regex pattern, consider using the "grep -l", aka "grep --files-with-matches", option.  It might be a wee bit faster or less consumptive of file system buffers on large files that have at least one match early on, and based on my 20 seconds of testing just now, it (grep -l) examines all files, whether binary or not, unlike the default grep, which without the -l option chooses not to search binary files, and complains (now on stderr) instead.

-- 
                Paul Jackson
                pj <at> usa.net

Message #32 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: gnu <at> tlinx.org
To: arnold <at> skeeve.com
Cc: 2773414454 <at> qq.com, 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Tue, 30 May 2023 14:01:02 -0700

On 2023/05/28 23:51, arnold <at> 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 <at> 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
>> 2773414454 <at> qq.com
>>
>>
>>
>> &nbsp;
>>     
>
>
>
>   

Message #39 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: "David G. Pickett" <dgpickett <at> aol.com>
To: "gnu <at> tlinx.org" <gnu <at> tlinx.org>, "arnold <at> skeeve.com" <arnold <at> skeeve.com>
Cc: "2773414454 <at> qq.com" <2773414454 <at> qq.com>,
 "63780 <at> debbugs.gnu.org" <63780 <at> debbugs.gnu.org>
Subject: Re: bug#63780: Reversing the grep message output type matching
 binary files (without the -a option added) changed from stdout to stderr
Date: Wed, 31 May 2023 19:17:15 +0000 (UTC)

[Message part 1 (text/plain, inline)]

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: gnu <at> tlinx.org
To: arnold <at> skeeve.com
Cc: 2773414454 <at> qq.com; 63780 <at> 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, arnold <at> 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 <at> 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
>> 2773414454 <at> qq.com
>>
>>
>>
>> &nbsp;
>>    
>
>
>
>  

[Message part 2 (text/html, inline)]

Message #42 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: gnu <at> tlinx.org
Cc: 2773414454 <at> qq.com, 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Wed, 31 May 2023 17:38:10 -0700

On 2023-05-30 14:01, gnu <at> tlinx.org wrote:

> Why is finding the desired text in a binary file not a "positive finding"
> as it is in a text file?

But it is a positive finding. Grep exits with zero status, which is a 
positive result.

There is no perfect solution here. In the old days when 'grep' reported 
the situation to standard output, this made stdout confusing and we got 
bug reports about it. Jim's earlier email 
<https://bugs.gnu.org/63780#14> briefly summarizes some of those issues. 
When we changed 'grep' to report the situation to standard error, we 
then got complaints the other way. In cases like this we just have to 
use our best judgment.


> 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.

If you merely want to find matching files, use 'grep -l'. Then the 
problem doesn't come up.


> 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.

Yes, and 'grep' must be particularly careful since it's so widely used 
and if it outputs random binary data to the screen it can screw up the 
user's terminal. This can even be a security issue. This is an important 
reason why 'grep -a' is not the default (though -a is there if you want 
it - presumably you know what you're doing if so).


> Noting a match (which is what grep should do), shouldn't be considered 
> an error

It's not considered an error. It's merely a diagnostic sent to stderr. 
They're not the same thing.

In that sense, it's like the diagnostic "recursive directory loop" from 
'grep -R'. That diagnostic is also sent to stderr, but it is not 
considered an error and it does not affect the exit status. It's sent to 
stderr because sending it to stdout would likely cause more trouble than 
it would cure.

Message #45 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 2773414454 <at> qq.com, 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Thu, 01 Jun 2023 07:50:06 -0700

On 2023/05/31 17:38, Paul Eggert wrote:
> On 2023-05-30 14:01, gnu <at> tlinx.org wrote:
>
>   
>> Why is finding the desired text in a binary file not a "positive finding"
>> as it is in a text file?
>>     
>
> But it is a positive finding. Grep exits with zero status, which is a 
> positive result.
>
> There is no perfect solution here. In the old days when 'grep' reported 
> the situation to standard output, this made stdout confusing and we got 
> bug reports about it. 
I thought binary files were skipped, by default these days (along with
directories).  Only if the user's grep includes binary files should they
get positive findings from binary files.

I think that's the deciding factor -- if they want to scan binary files as
well as text, then positive results should be printed to stdout.

If they want to avoid message about the pattern being found in binary 
files, they
have the option to not scan binary files.

I.e. the tools for them getting those messages or not were already 
present.  It seems
wrong to hamstring grep for those not knowing how to use the tool.


>   

Message #48 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 2773414454 <at> qq.com, 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Thu, 1 Jun 2023 14:18:46 -0700

On 6/1/23 07:50, L A Walsh wrote:
> I thought binary files were skipped, by default

They're not. The '--binary-files=without-match' option enables that 
behavior. With that option, this issue doesn't come up.

> if they want to scan binary files as
> well as text, then positive results should be printed to stdout

Not if that would screw up the screen. This is a real problem with 
arbitrary binary data, with real security implications.

Message #51 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 2773414454 <at> qq.com, 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Thu, 01 Jun 2023 22:36:26 -0700

On 2023/06/01 14:18, Paul Eggert wrote:
> On 6/1/23 07:50, L A Walsh wrote:
>> I thought binary files were skipped, by default
> 
> They're not. The '--binary-files=without-match' option enables that 
> behavior. With that option, this issue doesn't come up.
> 
>> if they want to scan binary files as
>> well as text, then positive results should be printed to stdout
> 
> Not if that would screw up the screen. This is a real problem with 
> arbitrary binary data, with real security implications.

If the output is displayed through a util like 'less', such binary data
is automatically filtered.


Perhaps it would be a good idea for grep to provide such filtering
(displaying <00><AH>, or such) for non-ascii data?

I have a command to restore my tty settings to the value they
were when I logged on.

Nevertheless, displaying <filename>: matches, without the text doesn't
seem to pose any security risks.

Message #54 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 2773414454 <at> qq.com, 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Fri, 2 Jun 2023 15:17:33 -0700

On 6/1/23 22:36, L A Walsh wrote:

> Perhaps it would be a good idea for grep to provide such filtering
> (displaying <00><AH>, or such) for non-ascii data?

You mean, migrate some of less's functionality into 'grep'? I suppose 
something like that might work, if someone put a lot of time into it, 
and carefully considered the backward compatibility issues, and tried 
things out on some real use cases. I don't have the time myself.

> I have a command to restore my tty settings to the value they
> were when I logged on.

That's not enough to address the security issues.

> Nevertheless, displaying <filename>: matches, without the text doesn't
> seem to pose any security risks.

Yes, and grep does that now. The only issue is whether to send that 
summary information to stdout or to stderr.

We seem to be going around in circles, so I'll let you have the last 
word if you like.

Message #57 received at 63780 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 2773414454 <at> qq.com, 63780 <at> debbugs.gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Fri, 02 Jun 2023 22:38:51 -0700

On 2023/06/02 15:17, Paul Eggert wrote:
> 
> Yes, and grep does that now. The only issue is whether to send that 
> summary information to stdout or to stderr.
---
If you want to send all matches from all files to one or the other, that's
fine -- the point is to be consistent: sending matches to one or the other.


> We seem to be going around in circles, so I'll let you have the last 
> word if you like.
---
	Only circles, because I don't see why some matches should be
sent to stdout and others to stderr.  Like the original poster - I feel
being consistent and sending all matches to stdout -- being the way it was
done since grep was created was fine.  Changing it so some go to stderr was
an inconsistent and arbitrary change.  Reverting that change seems like the best
course. 

If you want to give a user the last word, you would let their suggestion stand and the
change be implemented. It's dishonest to claim a user gets the last word while their
suggestion/correction is ignored.

Message #60 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul Jackson" <pj <at> usa.net>
To: bug-grep <at> gnu.org
Subject: Re: bug#63780: Reversing the grep message output type matching binary
 files (without the -a option added) changed from stdout to stderr
Date: Sat, 03 Jun 2023 11:05:48 -0500

L.A.Walsh wrote:

>> If you want to give a user the last word, you would let their suggestion
>> stand and the change be implemented. It's dishonest to claim a user
>> gets the last word while their suggestion/correction is ignored.

Having the last word doesn't mean dictating the result.
Paul Eggert was honest in stating he would not be replying
again in this discussion. 

Your view was not ignored.  There are conflicting issues on
this (and many other such) decisions.   Paul Eggert and others
working this issue have worked through these issues, made
a reasonable set of tradeoffs, and explained their decisions.

Thank-you, Paul Eggert, and others, for continuing to keep ed(1)
alive and well.  It's been my "standard text editor" for 45 years
now, and counting.  I'm glad it's in good hands.

-- 
                Paul Jackson
                pj <at> usa.net

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.