Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)
Wed May 9 19:00:00 GMT 2012
Daniel Colascione wrote:
> On 4/27/12 10:27 PM, Christopher Faylor wrote:
>> The above comment shows an "and" relationship here. Message type pipes
>> more closely mimic Linux (UNIX) pipe behavior AND are definitely
>> required for ptys.
> Yeah, but because message pipes break other programs. Cygwin has only
> been using message pipes since 23-Oct-11 (1.134), and it got along
> fine before that, ICANON aside. If Cygwin programs don't actually
> _need_ message pipes in the general case, Cygwin should use byte pipes
But Daniel -- if the point is to make cygwin behave like *nix, wouldn't it be
proper to use the method that most closely emulates it's behavior?
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
A suggestion for a workaround:
Write a simple C program as a pipe for stdin -- that buffers
the I/O by 'line' (or xx bytes). Then you can have it NOT do writes
of 0 bytes to MS progs.
You could even do it as a wrapper
avoidmsbug "normal progline with it's arguments"
avoid would open the appropriate pipes and do the buffering to
any buggy MS lib...
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.
Another approach in using the wrapper... Just have your
real program be named "xxx".bin.exe, and let "xxx" be a link to
"avoidmsbug.exe". That prog could look at it's name, automatically append the
".bin" to it's name to execute it...
Then you could have any number of cygwin programs with transparent wrappers
around them designed to deal with calling programs that mishandle pipe I/O...?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin