Is textpad really necessary in this regard !!!

[chsowjanya]

How can we code to change a file format from UNIX to PC in C# ???

[kenobewan]

Welcome to TSDN. Please provide more information. Thanks.

[Plater]

Generally the only difference between a UNIX-based text file and a windows-based text file is the use of the '\r' character.
Unix-based textfiles terminate lines with just a '\n' (line-feed)
While Windows-based use the "\r\n" combination (cariage return/line-feed)

So if you wanted to you could read in the file and replace the "\n" with "\r\n" and you should be able to read it normally.

[TRScheel]

Generally the only difference between a UNIX-based text file and a windows-based text file is the use of the '\r' character.
Unix-based textfiles terminate lines with just a '\n' (line-feed)
While Windows-based use the "\r\n" combination (cariage return/line-feed)

So if you wanted to you could read in the file and replace the "\n" with "\r\n" and you should be able to read it normally.

I have never had problems with text files that end in \n while reading them in Windows.

[Plater]

I have never had problems with text files that end in \n while reading them in Windows.

Well, I believe notepad doesn't view them correctly.
Also, some text editors (such as ultraedit, as I use) detect it and I have it set to ask me if i want to view it as a dos-style or unix-style.

[TRScheel]

Well, I believe notepad doesn't view them correctly.
Also, some text editors (such as ultraedit, as I use) detect it and I have it set to ask me if i want to view it as a dos-style or unix-style.

My notepad > your notepad?

Hehe, on a serious note, I have never noticed a problem viewing them. Something like:

StreamWriter SWriter = new StreamWriter("MyText.txt");
SWriter.Write("Test\nTest\nTest");
SWriter.Close();
 

Will produce a readable txt file for me.

[Plater]

Hehe, maybe they've upgraded themselves.
But for generic formating:
DOS Format - CRLF
UNIX Format - LF
MAC Format - CR
(Everyone's gotta be different)

As to the original question, maybe the difference in line terminators isn't the actual problem?

[christe]

QUOTE=TRScheel]My notepad > your notepad?

Hehe, on a serious note, I have never noticed a problem viewing them. Something like:

StreamWriter SWriter = new StreamWriter("MyText.txt");
SWriter.Write("Test\nTest\nTest");
SWriter.Close();
 

Will produce a readable txt file for me.[/quote]

Although your program writes seemingly only a \n from a c program, the binary file produced actually contains carriage return + line feed (x'0d0a'), on a windows platform. You can see this with a binary editor (I use spf/pc with profile 'exe').
Also, if you open an ordinary text file in c with binary mode fopen(<filename>, "rb") and read it then with fread -function , you can see x'0d0a' in the buffer.

Moreover, after "r" -mode fopen(<filename>, "r"),
fread suppresses all 2-byte CRLF (0d0a) to 1-byte LF (0a).
so you can only see x'0a' in buffer.

Also, if you ask for a file length in a c-program with a
fseek(fileptr, 0, SEEK_END); byteCount = ftell(fileptr);
the bytecount is the real length of the file, i.e. including
x'0d0a', not x'0a' (\n) only.

On a unix it is only x'0a' line separator in a text file. If you transfer a file from unix having x'0a' line separators, at least my notepad (5.1 sp2) can't show them properly, instead you see one long stream with non-printable byte where the line separator should be. But wordpad can read it, and when you save it, you have
x'0d0a' so it adds the 'x0d'.

[TRScheel]

My notepad > your notepad?

Hehe, on a serious note, I have never noticed a problem viewing them. Something like:

StreamWriter SWriter = new StreamWriter("MyText.txt");
SWriter.Write("Test\nTest\nTest");
SWriter.Close();
 

Will produce a readable txt file for me.

Although your program writes seemingly only a \n from a c program, the binary file produced actually contains carriage return + line feed (x'0d0a'), on a windows platform. You can see this with a binary editor (I use spf/pc with profile 'exe').
Also, if you open an ordinary text file in c with binary mode fopen(<filename>, "rb") and read it then with fread -function , you can see x'0d0a' in the buffer.

Moreover, after "r" -mode fopen(<filename>, "r"),
fread suppresses all 2-byte CRLF (0d0a) to 1-byte LF (0a).
so you can only see x'0a' in buffer.

Also, if you ask for a file length in a c-program with a
fseek(fileptr, 0, SEEK_END); byteCount = ftell(fileptr);
the bytecount is the real length of the file, i.e. including
x'0d0a', not x'0a' (\n) only.

On a unix it is only x'0a' line separator in a text file. If you transfer a file from unix having x'0a' line separators, at least my notepad (5.1 sp2) can't show them properly, instead you see one long stream with non-printable byte where the line separator should be. But wordpad can read it, and when you save it, you have
x'0d0a' so it adds the 'x0d'.

I just checked that, and it seems you are right. I had never noticed that.