Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)
Fri Apr 27 09:09:00 GMT 2012
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!
> 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
I tested with VC++ 2010 runtime and that still has the issue.
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
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
Unfortunately, this isn't a real workaround unless you remember to use
it all the time.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin