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] |
I can't say with 100% certainty, but I would bet with 90+% confidence that this is a bug in MS's libraries -- they "cheat" and use a null/0 byte read as a signal for end of file rather than sending out-of-band information that *nix supports.
From examining .NET Framework source, it seems clear to me they did not plan on message
Of course, these libraries are very widely used...
Essentially you need a 'shim' layer between a POSIX compliant subsystem to NON-POSIX compliant programs.
I'm sure that in the case that my assumptions are true, you wouldn't want to deliberate put something in cygwin that would make it less POSIX compliant when it is only to support external-to-cygwin, NON-POSIX compliant programs...
Note -- I use programs between cygwin and Windows 'alot', so I want these things to work as well.
Maybe I'm naÃve and this is harder than it looks, but couldn't Cygwin determine if
# Byte pipe used because Win32Program.exe does not link with CYGWIN1.DLLL cat Testfile.txt | ./Win32Program.exe # Message pipe used because grep links with CYGWIN1.DLL cat Testfile.txt | grep Hello # Message pipe still used because the program we are calling links with CYGWIN1.DLL ./Win32Program.exe | grep Hello
If that is still not POSIX compliant enough for the sending program
-- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |