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: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#23562: closed (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 message dated Tue, 22 Sep 2020 12:03:54 -0700
with message-id <919a9d20-a53d-7417-f46c-72d43e7eb443 <at> cs.ucla.edu>
and subject line Re: bug#23562: grep seems to write some error messages to stdout data stream --- shouldn't it be to stderr?
has caused the debbugs.gnu.org bug report #23562,
regarding grep seems to write some error messages to stdout data stream --- shouldn't it be to stderr?
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> 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: "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

[Message part 3 (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

Previous Next

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