This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)
- From: <cygwin at alanhowells dot e4ward dot com>
- To: cygwin at cygwin dot com
- Cc: jamesj at motionview3d dot com
- Date: Fri, 27 Apr 2012 10:08:23 +0100
- Subject: Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)
- References: <email@example.com>
- Reply-to: cygwin at alanhowells dot e4ward dot 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!
> 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