Message-ID: <4BCCE953.90204@redhat.com>
Date: Mon, 19 Apr 2010 17:37:55 -0600
From: Eric Blake <eblake AT redhat DOT com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: cygwin AT cygwin DOT com, GNU <bug-grep AT gnu DOT org>
Subject: Re: Spurious 'grep: writing output' in Cygwin 1.7.5-1 in certain  cases
References: <CE4D3C6371BA4722B73A7015133FC9B6 AT ghc DOT local>
In-Reply-To: <CE4D3C6371BA4722B73A7015133FC9B6@ghc.local>
Content-Type: multipart/signed; micalg=pgp-sha256;  protocol="application/pgp-signature";  boundary="------------enig2D7FC13D8C3CC5A2DF25B5F8"
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

--------------enig2D7FC13D8C3CC5A2DF25B5F8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

[adding bug-grep]

On 04/19/2010 03:19 PM, Matthew Kidd wrote:
> We are seeing grep emit 'grep: writing output' multiple times in
> certain cases where the output of grep is piped to another program.
> Specifically, we see it in the following cases:
>=20
>   grep thisandthat foo.txt | head
>   grep thisandthat foo.txt | less

Expected, if you are blocking SIGPIPE, although it might be improved a
bit.  Grep is telling you that it encountered a write failure due to
EPIPE, and is thus about to exit with non-zero status.  Did you paste
the full error message?  On Linux, I see:

grep: writing output: Broken pipe

with the errno being converted to a string to make it obvious.  If
cygwin is not printing the EPIPE errno string as part of the error
message that you are seeing, then that could be improved; it's hard to
tell from your report, though.

> There appear to be two 'grep: writing output' messages for each
> line grepped.

That is indeed annoying; but it is not cygwin-specific.  It would be
nicer to print a failure message exactly once in the case of EPIPE write
failure, rather than once per matching line.  Would you care to
contribute a patch?

>=20
> Not all pipe operations exhibit this behavior. For example with the
> same file, we do not see it in either of these cases:
>=20
>   grep thisandthat foo.txt | last
>   grep thisandthat foo.txt | wc

Also to be expected - it is a factor of how much data the kernel can
push through a pipe.  You only get EPIPE write failures if SIGPIPE is
being ignored, and if the writer (grep) tries to push more data into the
pipe after the reader is done.  As readers, last and wc consume the
entire stream, but head and less can exit early, in which case the
kernel pushes back to the writer.  Another thing to note; you will only
get the errors for large files; for smaller files, the entire file can
be written into the pipe before the reader exits.

>=20
> Moreover a non-piped grep does not exhibit this behavior:
>=20
>   grep thisandthat foo.txt

Of course, because there is no EPIPE write failures if stdout is not a pipe.

> Note: in this case 'grep: writing output' does not appear in
> out.txt; my guess is that they are being sent to STDERR when they
> do occur.

Yes, POSIX requires that error messages, such as diagnosis of write
failure due to EPIPE, goes to stderr.

By the way, if you don't like this message, then consider changing your
environment to not ignore SIGPIPE.  Then grep will silently die from a
signal, instead of noisily exiting with an error message.

--=20
Eric Blake   eblake AT redhat DOT com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


--------------enig2D7FC13D8C3CC5A2DF25B5F8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJLzOlXAAoJEKeha0olJ0NqFC4H/0lFAxItQDLAFUhUx2SBNsNT
UPuA+2vIeEXLu128RSSw5dXAaDMNOfM1u2yLOsZ5BJrDclUSYVlOQAqvtSr0q+08
MZNsILsRMMRXis+rmx7LZJlJtZ+Jlj/qPK4MZ5uWf/EmThXrjEpxC+xkoyscUXcN
HgdodaQN5wAYM3NNdej9RwwHN99nG7PXqqxqO0vHA3ypDRlOgvKTl5bz5OtoLxSV
7czyF2+Dmer21hlW1eFSrNtaNgqhVgtgkbiqZxMbTh05szOMvpbtC9P/FBbw/CKQ
QmxkTgKw0UM3LiLkl17Wbh76UM/9igKKDMo/777BXWuhAb+zOV7J9h6ME7odKFg=
=qZgB
-----END PGP SIGNATURE-----

--------------enig2D7FC13D8C3CC5A2DF25B5F8--