Well, if \n\r is so pervasive that it's in the file formats used by the MUD, it's more than a search-and-replace. You could probably write a filtering function and call it on all data you're sending to the user, and have it replace \n\r with \r\n. That would let you conform for the most part, while still using \n\r internally.

How is it not a search-and-replace? So, you have to do the same search/replace on your data files as in your source code…
The only distinction is, for data files you probably need to search for the ASCII characters directly, rather than the C symbolic form of them.

Yes that is what I meant by at least I will fix the messages. It is a shame that the 'cleaned ROM' with g++ still use the wrong order though.

And fix the algorithms that read your files, as Rarva pasted a snippet that explicitly puts an '\r' after any '\n' it receives.

Also, I think I was wrong about the file format thing - in the code snippet Rarva pasted, it looks like it's adding \r's whether or not there's a \r following the \n in the data stream, so I suspect the file format actually just uses \n. That doesn't invalidate my point about fixing the algorithms though.

Because fread_string is not the only method to modify by just a 'search and replace'. And forget only one and it is a mess. I never said it was a hard job either. Just that is not a simple search and replace, and that telling that was overly optimistic.
But you are all so great coders that you do it in 5 mins…..in your heads (funny that none of you bothered to update any of the code here….)

But you are all so great coders that you do it in 5 mins…..in your heads (funny that none of you bothered to update any of the code here….)

:devil: It's far easier to criticize the community members that don't really understand standards than it is to show them.
Besides, they said what was wrong, now we get to ask how to fix it until we get real answers. :devil:

Well, that's true enough, but I should note that over the years this topic has came up many times and generally people go, 'oh, now that I know that I'll fix it.' This particular time people seem to have rebelled against the very notion that \r\n is the correct way. Which is silly. Some people who otherwise don't care to engage in a discussion teaching these things might be inclined to correct the record when a falsehood is being perpetrated on the entire community at large. It doesn't really do anyone any good to just let it stand. Plus, if you disagree, you can always debate it. Hopefully the best argument will come out on top.

There aren't any publicly released Diku muds that use \n\r in their zone/area files.
Altering the mud to send the proper Telnet line sequence does not entail converting anything.

VT100 is the dominant standard for MUDs, as such \n, \n\r, and \r\n are all valid, though I've observed a single \n doesn't properly work with Windows telnet in some instances.

orlly?

Windows Telnet and many commercial Windows Telnet clients correctly implement '\n' as advancing to the next line. Some versions of BSD Telnet handled this correctly too. Sending "H\ne\nl\nl\no\n" should display the following on a Telnet client.

H
 e
  l
   l
    o

Yes?

…Sorry, what? VT100 is a terminal type, and Telnet is a protocol for terminal communication. Telnet was explicitly designed to have a single interface for multiple terminal types. Some terminals behave differently than others, and this is the whole reason "\r\n" was chosen as the definitive end-of-line marker.

Sorry, I missed reading your later post. Yes, that's correct.
And kudos for posting the simple fix.

Nevermind, not worth it…

Not as far as Scandum is concerned. To him, everything is VT100 compatible, and the few people who might be on terminals that don't support it can just upgrade to something that can. It's the old "when all you have is a hammer, everything looks like a nail" syndrome. It's also a matter of effort involved. Let's face it, it's MUCH easier to just assume vt100 works and hard-code your screen controls, rather than spend the time needed to learn how the termcap/termlib system actually works and write all the extra code to lookup the proper sequences for a given TTYPE.

Oh, and the argument will also be made that most MUD clients aren't in the standard termcap database, and so it's utterly impossible to work with that system, even though you could probably merge local termcap entries into the lookup routines if you can't get the sysadmin to add them to the system database.

http://i.imgur.com/RHEw6.jpg

Works, so I ain't fixing it!

It "works" because of the meaning of the terminal characters. If you don't want to fix it, then don't – but please don't ask other people to stay broken too. You've been given any number of reasons why it's broken.

lol'd at the picture though.

If it's good enough for VT520 it's good enough for David Haley.