A habit of mine from working on a lot of smaug code is to always send \r\n. But,is the carriage return really necessary to send? Receiving one from a client makes sense but sending one seems… well, not needed. Or, maybe I just don't know much about the client side of muds.
The end-of-line marker on most of today's operating systems is \n, however on DOS/Windows it has always been \n\r. Prior to OSX, the original MacOS used \r for their end-of-line marker. So the sequence \n\r was and still is displayed correctly by most popular home systems without special code in the client.
Also, some early form of Diku made the mistake of using \r\n for all line terminations. Since this was still interpreted correctly most of the time, most of their descendants (including Smaug, it would seem) still use \r\n.
Also, some early form of Diku made the mistake of using \r\n for all line terminations. Since this was still interpreted correctly most of the time, most of their descendants (including Smaug, it would seem) still use \r\n.
Actually, DikuMUD uses the incorrect \n\r line ending because… college drinking? At any rate, most of the surviving codebases that are still somewhat maintained have corrected that. Since most DikuMUD's don't actually implement TELNET at all, they never saw the problem, but you can see it if you use a client like tinyfugue.
In particular, when you connect to a DikuMUD that uses the old backwards endings, and you try to define a trigger that matches text at the beginning of a line, it won't match… Because there's a leading \r that is invisible (a CR at the left margin does nothing).
So, as long as you're sticking with TELNET-like connections, use CRLF. It's correct. MUD clients will deal with it even if they aren't fully TELNET compliant (worst case is end-anchored regexp matches will fail), and it keeps stuff somewhat sane. :)
02 Mar, 2015, Hades_Kane wrote in the 5th comment:
Votes: 0
Shortly after reading on this site that the \n\r was incorrect, I went through and corrected every instance of that in my game.
Not that I intend on ever using C for anything else, I still figured it was a good habit to pick up doing correctly.
Use a single '\n' in all your data files, code strings, help files, etc. Your socket stack should have a translation layer which converts the '\n' into the appropriate line break, whether CR/LF pairs, html <br> tags, normal '\n' for custom clients, etc. Same thing with color tags. Changing '\n\r' order should be a ten second change and recompile of the socket stack filter.
BTW If you ever do want to send a \r without a following \n Telnet mandates that it MUST be followed by an ASCII \0 {NULL} character I believe for it to be interpreted as a carriage return.