Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)

[<cygwin@alanhowells.e4ward.com>]

On 26 April 2012 22:18, James Johnston <JamesJ@motionview3d.com> wrote:
> I have "run into an issue with Cygwin".  This is arguably not a bug in
> Cygwin, but in other platform runtime libraries.  Never-the-less, the
> symptoms occur only with Cygwin and not the Windows command prompt.  So,
> from a practical standpoint, Cygwin is "broken."  This is almost certainly
> the same issue mentioned in the "1.7.10->1.7.13 : output from .NET programs
> does not get through pipeline to a visual c++ program" thread started by
> cygwin AT alanhowells.e4ward.com last week.  It's also related to the issue
> I raised over a month ago, titled "Can't reliably redirect standard output
> from C# program in recent Cygwin".

Thank you! It is good to see someone else reproduce this!

<snip>

> I am providing several sample programs that can be compiled in Visual C#
> 2008 / .NET Framework 3.5, or Visual C++ 2008.  They should demonstrate the
> problem 100% of the time on any system, because appropriate Sleep() calls
> are made.

Of course, why didn't I think of using Sleep??

When adding sleep to my test programs, the test where it failed on the
first attempt reliably fails.

I think I hinted at an issue with the VC++ runtime as I proved that
using the Win32 API calls succeeded, but unfortunately didn't follow
that through.

I tested with VC++ 2010 runtime and that still has the issue.

<snip>

Christopher Faylor says
> Nope, it won't always be that because I get what's expected.  I built
> the C++ files using mingw g++.  Although I actually expected the reader
> to honor the null byte, it did not.  Perhaps you are using a different
> version of Windows than I am or a different runtime.

But the point by James is that it is the VC++ runtimes (and .NET
runtimes) that think that a null write is EOF. Other runtimes may not
(e.g. mingw).

I agree with James that the runtimes are probably buggy BUT I also
agree that cygwin should be able to have a handle these scenarios.

I have also found a workaround, by piping through a cygwin command,
you lose the null writes, a good one to use is cat so:

$ ./SenderC | cat | ./ReceiverCPP
$ Got line Hello world!
$ Got end-of-file
<snip>

Unfortunately, this isn't a real workaround unless you remember to use
it all the time.


Alan

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