Now that I have Samba set up to see Windows shares from my Suse Linux system I want to share some text files.

When I edit a file in Windows using the default Windows ASCII text editor "Notepad" I can read it OK in Kate or Kwrite from Linux.

But when I edit a file in Kate or Kwrite on Linux, it loses all linefeed information in Notepad!

I assume this is because of the different ways they treat end-of-line cases. (Windows uses CRLF, Linux apparently just uses LF). How do I get around this? I assume there's an option on the Linux side to do a Save As in a format that looks like the Windows format. Under kate there seems to be several dozen "Save As" format options.

In kate, under the "tools" menu, there's an option to set the "end of line" type.

well windows does its best to be incompatible at all times............

I don't use "notepad or wordpad" in windows.......I use Utraedit32........
this is a great text/hex editor and I can also write Macros with it..........
There is really Nothing wrong with the way your Linux system saves text files..........its the way windows interprets them!! Not really sure how you can
force windows to play nice............other than using a different windows text editor------

Window wordpad will decode a linux ASCII textfile correctly but not save as one. If editing linux config files in windows make sure that they are saved or converted to a unix format. Some applications like Apache will fail to start if the files are saved in a DOS format.

I use EditPad and it can read Linux files and convert between Windows/Linux end of line characters.

Another vote for Ultraedit, simply awesome program. Wish there was a unix/linux port, although it will run from Wine.

I like the windows Textpad ASCII editor myself. It can also save in either format.

i use unix2dos in a windoes batch script that copys/converts files from a RH7 server.
It does the job

My understanding is that Windows ASCII requires carrige returns and linefeeds as two different characters (hex 0D, hex 0A). Since carriage returns and linefeeds really do represent two distinct behaviors it seems perfectly logical to distinguish between them.

I also question your observation about "compatibility" since Windows is on about 90% of desktops worldwide, so whatever Windows does is, by definition, the most compatible. It's the same reason why Star Office / Open Office -type programs make sure they're compatible with Windows word-processing and spreadsheet file formats but Windows has no need to be compatible with Unix/Linux formats.

Anyway the solution suggested by CSixty4 is the most logical one. Using a new editor such as Utraedit32 or Textpad in order to read and edit the Linux-edited files would be impractical because it would require that every Windows PC on our network use that editor, including visitors who just happen to bring their own laptops.

But linux programs will read 100% of text files - windows will only be happy with those saved in its own format. Likewise linux has built-in (or at least the option to build in) support for most types of filesystem, windows will support only its own Being the most popular doesn't make it the most compatible, if anything it means less popular systems must make extra effort to support all formats and will therefore be more compatible than windows or risk not catching on. Being most popular and being on the most systems does not make something more compatible "by definition" it makes it more available.

It is being able to accept the widest range of formats that makes something 'more compatible', not having its own format as the most common.

To me "most compatible" refers to the format that is read AND WRITTEN by the largest number of actual systems. So, to me, "most compatible" does equate to most popular.

Thus, by default, the Windows format can be read by 100% of computers, and is the one written by 90%. The Linux format is only read by default by Linux (and Mac's?).

That's why I said that the solution suggested by CSixty4 - setting kate to use the Windows end-of-line type - produced the most compatible result because it would then be readable by default by the vast majority of computers.

Ah, you would be referring to the file format - I was referring to the nature of linux programs. We're both right, I like that outcome