Date: Wed, 9 May 2012 16:11:47 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)
Message-ID: <20120509201147.GD22015@ednor.casa.cgf.cx>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <020501cd23f2$20f07620$62d16260$@motionview3d.com> <20120427143753.GO25385@calimero.vinschen.de> <025501cd24c6$6a353990$3e9facb0$@motionview3d.com> <4F9B38FB.9030607@dancol.org> <20120428052727.GA23749@ednor.casa.cgf.cx> <4F9BD262.2000403@dancol.org> <4FAABEAE.7000309@tlinx.org> <053b01cd2e18$f3f9ce60$dbed6b20$@motionview3d.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <053b01cd2e18$f3f9ce60$dbed6b20$@motionview3d.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Wed, May 09, 2012 at 07:21:34PM -0000, James Johnston wrote:
>On Wed, May 09, 2012 at 11:59:58AM -0700, Linda Walsh, the dead discussion resurrector wrote:
>>I can't say with 100% certainty, but I would bet with 90+% confidence
>>that this is a bug in MS's libraries -- they "cheat" and use a null/0
>>byte read as a signal for end of file rather than sending out-of-band
>>information that *nix supports.
>
>Maybe I'm na??ve and this is harder than it looks, but couldn't Cygwin
>determine if the program being piped to links with CYGWIN1.DLL (or
>similar detection technique), and then use byte or message pipes
>accordingly?  Example:

You're being naive.  Of course this is harder than it looks.  Or, if it
really is so easy, why haven't you submitted a patch or at least a
proof of concept?

># Byte pipe used because Win32Program.exe does not link with CYGWIN1.DLLL
>cat Testfile.txt | ./Win32Program.exe

In the above, the series of events are likely something like:

1) Shell creates a pipe

2) Shell starts cat with its stdout set to the output side of the pipe, first
closing the input side.

3) Shell starts ./Win32Program.exe with its input set to the input side of
the pipe, first closing the output side.

4) Shell closes pipe.

5) Processes execute.

The cygwin DLL can't intercede here.  It's not some superior process
controlling I/O.  It's just a DLL used by two programs.  cat is writing
to the stdout that it inherited from the shell.  It doesn't know (and
shouldn't know) what's on the other end of the pipe and that it should
be changing the mode of the pipe.

Please stop thinking that there is a simple solution that you can
intuit without fully understanding how Cygwin works.

1.7.15 will contain a new CYGWIN option "pipe_byte" which will force
non-tty, non-fifo pipes to use byte mode.  That's about as far as we're
willing to modify Cygwin for this apocalyptic problem.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple