At 21.05 09/13/02 +0200, Carlos Garc=EDa del Monte <cg...@wo...> wrote:
>With an experiment with a text editor made with a simple edit control,
>I've found some files, like winerror.h, where the text displayed has no
>new ines, instead it has a giant line with vertical bars where the
>newline should be. I tried write a small program which reads the file
>until the second line has begun and returns each character behind the
>numeric value, but in the new line it puts in the console the value 10,
>which is the usual of the newline. And in other place I found that some
>file has value 13 where the newlines are, so now I test for one of them
>and change to the other, but that doesn't solve the problem, what it
>makes is that all files has a vertical bar where the newline should be,
>and I don't find the way to make the program show newline in those
>places.
>Any idea?
>Thanks.
As Horst says, you are dealing with some Unix file which was "binary"=20
copied to Windows. Beside his solution, surely the quickest, here is my=20
idea. Hope it works! :)
As I said, the Unix file was "binary copied" to Windows, so Unix newlines=20
(LF) where not translated to Dos (CR LF). Now, if one reads the file and=20
then writes it again, using some simple program compiled on a Windows=20
system, then the copy should be OK. In other words, the "stdio" of Windows,=
=20
knows that on Dos systems, newlines are sequences of CR LF, so when asked=20
to write an LF, actually a CR LF sequence is emitted.
Here is the simplest version of a copy program I can think of, try it and=20
let us know.
dosfy.c
-------
#include <stdio.h>
int
main()
{
int c;
while ((c =3D getchar()) !=3D EOF)
putchar(c);
return 0;
}
--
gisan
|
