I failed to see your point, Twisol. Please explain.

There is no reason to require support for LF CR in the standard, and the Telnet protocol would not incorporate such a change even if it were still actively maintained. It brings no useful added functionality, causes inconsistencies and minor issues of its own, and the only people who want it do so because they or their predecessors messed up years ago and don't want to fix it.

If you as an individual server or client want to support it, more power to you. I want to emphasis that you're on the borderlands of the standard - don't expect to have universal support.

I believe there is. I tried to explain why.

I'm aware of that. That's why I tried to suggest accepting LF CR inside our community. I suggested to stop telling people to replace LF CR with what the standard says. Many, many MUD servers use LF CR anyway, and many, many clients understand LF CR anyway. It is standard and I suggest we accept it as it is.

It brings wider interoperatibility. I tried to explain why.

What inconsistencies and minor issues?

As I said, I really wanted to replace LF CR with CR LF. And, ironically, I brought this into discussion exactly because I have planned to fix LF CR in my MUD. Other MUD admins just don't care as long as it works. And it does work already, and the only thing missing now is wide acceptance.

Just a thought. DecafMUD supports LF CR because I'm one of those "who don't want to fix it". There are a lot of other MUDs sending LF CR and if you want your client to be able to display their output properly, you will have to implement it as well. Because, as I said earlier, it actually already is a standard - de facto.

Well, you can submit the standardization request to the Telnet working groups and to MudStandards, and let us know how it goes.

I'm not sure why it's even worth spending time on this…

Because of the two competing delimiters, you'll find that clients have moved towards a third option: treating LF as the delimiter and stripping out CR altogether. I noted that I'm fine with using LF as a delimiter.

LF CR is bad because Telnet states, if CR is not followed by LF it must have a NUL prepended. LF CR by all rights should be LF CR NUL.


That doesn't invalidate my point. You use LF CR to mean the exact same thing as CR LF. The difference is that the standard doesn't require LF CR to have the same semantics as CR LF, meaning you have to special-case your behavior to handle the mutation. I can accept that LF CR has taken root, but that does not by any means make it acceptable to use in new code. It simply means clients have to do unnecessary work to handle it.


I already named them. CR must be followed by LF or NUL, meaning LF CR should really be LF CR NUL. LF and CR may have different semantics when used separately (CR NUL LF or LF CR NUL) than CR LF (which the spec requires to have a specific behavior).


It's widespread "accounted for" in most clients. It is by no means guaranteed to work, and I've explained why it shouldn't be guaranteed to work. It's true that unless you're using CR in places other than newlines, you won't have any dire need to change, but by changing the client to accommodate the mutation it limits what servers can do with CR. I mentioned before that many clients simply strip all CR's. Unfortunately that's the best you can expect - most clients don't want to figure out how to gracefully handle misplaced CR's while leaving others unchanged. But just because LF CR is ingrained in a few codebases doesn't mean new MUDs should use it too.

Forgive the double-post, but I have a somewhat better example of why LF CR is faulty. If you take 'LF CR' and define it to be a valid end-of-line marker, what happens if you want to send a series of 0-delimited strings separated by LF CR? In particular, what happens if you send an empty string? Yep… LF CR NUL! A standards-compliant parser would turn that into LF CR, because all CR's must be followed by LF or NUL, meaning you lose the NUL byte. Then when you're processing the strings you received, you try to use that empty string and you discover it's not properly terminated!

And since I know this is coming, CR requires a NUL after it so that you can safely wait on the CR to see what comes after it. If it's a NUL you can treat it as a CR, if it's an LF you treat it as an end-of-line. Removing the NUL from the spec means that you either have to get CR LF in the same packet, or be forced to wait forever if there's no LF forthcoming and the remote end isn't sending more data. Telnet wasn't designed by idiots, I'm afraid - there are very good reasons it's designed the way it is.

Because that's what the Diku developers did, and all the lazy gits that came afterwards assumed their gods couldn't possibly have made a mistake.

Why should you care? Because doing it backwards breaks trigger parsing in many clients. Even if the display is fine, many clients provide regular expressions to match patterns. If you make such a pattern that's anchored at the start of the line, on a MUD that does things backwards, the start of the line is actually a "\r", which means it usually won't match.

Just do the handful of search/replaces you need to make it work right, instead of spending pages trying to justify doing it wrong. People using clients that handle both won't notice. People who use clients that expect it to work right will suddenly find stuff actually works as expected.

A shocking notion, but true! :tongue:

Wow! That's a mystery solved!! A long time ago when I used gmud, you usually had to put a '*' before each match so it'd trigger off. Was so annoying, but it prevented stupid people from setting up triggers :P.

Err I am not spendingpages justify doing it wrong…I just wanted to understand why it happened in the first place, and I wil change it in my code….considering how easy it is to fix it.
I just wonder how come it never been fixed….even in 'cleaned' code. Even KaVir snippet use \n\r

It certainly does not.

So much hostility lately on the forums… Everyone take some xanax and chill.

… and back to the original topic at hand… Thank you to whoever gave the buf3[0] = '/0'; - lost track within the bickering. :tongue:
Also, I would like to add that I don't think I've ever seen \n\r as /n/r, not even in any of the newer snippets or any code that I've scrolled through or had other code other people have added.

No, I can't imagine you have.

Well maybe it doesnot use it as I did not analysed the code but in all the install text that comes with it I see:
Replace this:

/*
* Initial \n\r if needed.
*/
if ( d->outtop == 0 && !d->fcommand )

With this:

/*
* Initial \n\r if needed.
*/
if ( d->outtop == 0 && !d->fcommand && !d->pProtocol->WriteOOB )

etc…maybe you should modify them to stop the spreading of a bad practice :)

Firstly, that's not the snippet, it's the installation instructions for a Diku derivative - and we've already established that Diku sends \n\r instead of \r\n.

Secondly, that's not my addition, I'm just indicating where abouts in the Diku code you need to look.

Thirdly, it's only a comment, it's not actually sent to the user.

The installation instructions are there to show you how to install the snippet, not to preach coding standards. However my actual snippet uses \r\n.

It appears that I had the wrong concept while reading through this post. Why should we \r\n besides its telnet friendly? Does it change any status of the code or anything major? Also, I don't see why such a fuss over this.
Simply put doesn't \r mean return, and \n new line?

I know you have to look for original bad Diku code, but since you then replace (comment included) you should put /r/n in the comment replaced command. It would at least make people think about it. I only used \n\r because well it was everywhere the same. if I had both version I would have looked wich one were the right one if any.

See explanation about triggers as an example of why it can pose problem with conservative client.

Don't care about triggers. Triggers I believe deplete game play experience. You should learn to expect what is coming and time it yourself, not rely on a program to do your work for you.