This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 26 April 2012 22:18, James Johnston <> 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 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
that through.

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

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]