Thomas Seeling schreef op 09 Apr 1996 om 14:10 aan Ruud Senden:

 RS> The problem is that this reading goes wrong whenever such a block
 RS> contains one or more newline-characters. If this happens, some 
 RS> other character in the same block is duplicated. However, when I 
 RS> change the mode of the pipe to binary using setmode(), everything 
 RS> works correctly. But setmode() is listed as PC-compatibility, so 
 RS> this function probably isn't available under UNIX.

 TS> Change the makefile to link with binmode.o/obj for the OS/2
 TS> version. 

Thank you for your answer. Linking with binmode.o indeed makes using
setmode() unneccessary.
However, it would be better if I could read the pipe in textmode, because I
want CR/LF-pairs to be converted to newline-characters.

 RS> text-mode, so I think this is a bug in emx. Can somebody confirm
 RS> this? And
 TS> This is no bug, it is listed in the "hints for porting unix". 

As I read it, "hints ..." says that you have to use O_BINARY or
"b" when reading binary data or files which contain both textual
and binary data. 
However, the pipe I'm reading from only contains plain text and
CR/LF-pairs, so I think I should be able to read it in text-mode (and this
works correctly under UNIX). However, in text-mode under OS/2, characters
are duplicated when CR/LF-pairs occur.  

It looks like the CR/LF-pairs are converted to a single newline-character,
then the rest of the string is moved one character to the left to fill the
freed space, but the \0 isn't moved with the rest of the string. So, for
example, if you have 10 CR/LF-pairs in one read block, then the last 10
characters in the pipe appear twice at the end of the read string.

So I still think this is a bug. Or I'm misreading the hints-section, and it
is saying that you should open every file in binary mode.

 RS> emx? And what is the latest version of emx?
 TS> 0.9b Fix #3. Subscribe to the mailing list emx{at}iaehv.nl, it is
 TS> worth it. All the high society :-) is reading and writing there,
 TS> including EM, Holger Veit, Dale DePriest, ...

Thank you for this suggestion, I will look at it.

Regards, Ruud 

--- timEd/2 1.10+