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