Problems with file type of "netscape"!?

smeo00 · Post by **smeo00** » Mon May 08, 2006 5:16 pm

Hi All,

I have a problem that I can resolve easily enough but dont understand how it came about.

I opened a text file with tp 4.7.3 (registered) and made some mods, I then viewed the file with IE6 and noticed a bunch of extra newlines between the text. When I looked at the file properties in tp it said the following:

Code set: ANSI
File type: Netscape
etc.

as a test I did the following:

opened the file in tp again with;
File format: auto
Encoding: default
in the open file dialog.

Completely deleted the contents and typed the following:
begin[CR]textpad[CR]end[CR]
and saved with:
File format: no change
encoding: ANSI

I then opened the saved file as hex and got this:
0: 62 65 67 69 6E 0D 0D 0A 74 65.......

So,
1. What made tp decide the file was in "netscape" format, esp since it isn't an option to save as type netscape?
2. Why did it insert 0D 0D 0A as the EOL str for my newly entered text?

Any help appreciated,
Smeo00.

ben_josephs · Post by **ben_josephs** » Mon May 08, 2006 6:37 pm

What TextPad calls sometimes "file type" (in the Properties dialogue box), sometimes "file format" (in the Save As dialogue box) is the line ending style of the file.

"PC" format line endings are CR LF (0D 0A).
"Unix" format line endings are LF (0A).
"Mac" format line endings are CR (0D).
"Netscape" format line endings are CR CR LF (0D 0D 0A).
"Unknown" format line endings are mixed up.

If TextPad describes a file as having "Netscape" file type, it found that the file's lines end with CR CR LF. If you save it with the same format, TextPad will end all the lines with CR CR LF.

"Netscape" format is not a desirable format (it is not a pure text file by anyone's standard), so, while TextPad will preserve that format in an existing file, it doesn't offer to create files with that format or to change a file so that it has that format.

Why your file should have these odd line endings is anybody's guess. Perhaps a dumb UNIX-to-PC text file conversion program added the CRs without realising they were already there.

smeo00 · Post by **smeo00** » Tue May 09, 2006 10:42 am

Thanks Ben,

Not sure how it came about myself, probably happened when our config managment guys checked my code into our unix based ccm from my pc many moons ago. They probably used some funky hacked script to ftp and dos2ux the source into the database.

I looked in the tp settings for a way to force the format automatically on save but all I can find is the default for new files. guess I'll have to get into the habit of checking any files I mod before saving until I purge any more of these cases, downside is that it'll mess up my diffs.

Thanks again for the explanation of tps open/save logic, cleared that right up!

Smeo00.

ben_josephs · Post by **ben_josephs** » Tue May 09, 2006 11:30 am

It's not the conversion from PC to Unix format that's done this but the conversion the other way round. Perhaps the files are stored on the Unix box without line-end conversion (so they keep their PC line endings), but fetched with (dumb) line-end conversion (so LF is blindly converted to CR LF, resulting in CR LF being converted to CR CR LF). If this is what's happening, it would be wise to fix the problem to avoid an endless increase in the number of CRs.

My solution to this problem is never to use PC line endings except where required by bad software that demands them. And the solution to the problem of such software is not to use it (but there's not much of it left anyway).

Diffs ignoring white space should ignore differences due to the presence of CRs.