GNU bug report logs - #23562
grep seems to write some error messages to stdout data stream --- shouldn't it be to stderr?

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: "John Refling" <netbsdrat <at> gmail.com>
Subject: bug#23562: closed (Re: bug#23562: grep seems to write some error
 messages to stdout data stream --- shouldn't it be to stderr?)
Date: Tue, 22 Sep 2020 19:05:02 +0000

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

Your bug report

#23562: grep seems to write some error messages to stdout data stream --- shouldn't it be to stderr?

which was filed against the grep package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 23562 <at> debbugs.gnu.org.

-- 
23562: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23562
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: John Refling <netbsdrat <at> gmail.com>, 23562-done <at> debbugs.gnu.org
Subject: Re: bug#23562: grep seems to write some error messages to stdout data
 stream --- shouldn't it be to stderr?
Date: Tue, 22 Sep 2020 12:03:54 -0700

On 5/16/16 11:03 PM, John Refling wrote:

> error messages should NEVER be injected into the same stream as the
> users input / output data, firstly because it corrupts the data, and
> secondly if the output is redirected, the user will never see the error
> message.

On further thought (and after getting other bug reports) you make a good point, 
and GNU grep's binary-file diagnostics will be sent to stderr instead of stdout 
starting with the next release. See:

https://git.savannah.gnu.org/cgit/grep.git/commit/?id=271793f09cc604ad54ad89b18110716555cc748b

[Message part 3 (message/rfc822, inline)]

From: "John Refling" <netbsdrat <at> gmail.com>
To: <bug-grep <at> gnu.org>
Subject: grep seems to write some error messages to stdout data stream ---
 shouldn't it be to stderr?
Date: Mon, 16 May 2016 23:03:01 -0700

I noticed this when I had an issue with 'binary file detection' discussed
in bug report #22838.

In 2.24 when the binary file detection triggered, not only was some of my
output data missing (since processing stopped), there was no error message
since grep sent that error message to stdout, along with part of my data.  I
was piping the output to another process.

I just built latest 2.25, and the binary file detection is improved, but the
error message STILL is hidden, since it is sent to redirected stdout, along
with data.  Verified by building 2.25 on Cygwin and FreeBSD.

A contrived example:

server-grep-2.25> ./src/grep.exe . src/grep.exe > x

server-grep-2.25> cat x

Binary file src/grep.exe matches

IMHO, error messages should NEVER be injected into the same stream as the
users input / output data, firstly because it corrupts the data, and
secondly if the output is redirected, the user will never see the error
message.

Not sure if this affects all error messages, or just the 'Binary file FOO
matches' message.

Relevant areas of src/grep.c are:


printf_errno (_("Binary file %s matches\n"), filename);

printf_errno (char const *format, ...)
{
  va_list ap;
  va_start (ap, format);
  if (vfprintf (stdout, format, ap) < 0)      // should be stderr IMHO
    stdout_errno = errno;
  va_end (ap);
}


Seems to me that grep should NEVER add more data to the output stream than
was in the input stream (by adding anything, including error messages).

Just seems wrong.

Shouldn't there be exactly the same or less data, and not new data in the
output that was not even part of the original input data?

My 2 cents,

John Refling

Previous Next

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