LimpingNinja
commented
5 years ago It appears to be as I expected:
RanvierTelnet.js On entry, databuf (toString()) = "Test\n"
The loop on line 252-262 checks for \n, pushing each char to the buffer databuf. This leads to databuf being: "Test".
// If multiple commands were sent \r\n separated in the same packet process
// them separately. Some client auto-connect features do this
let bucket = [];
for (let i = 0; i < inputlen; i++) {
if (databuf[i] === 3) { // ctrl-c
continue; //eat it
}
if (databuf[i] !== 10) { // \n
bucket.push(databuf[i]);
} else {
this.input(Buffer.from(bucket));
bucket = [];
}
}
if (bucket.length) {
this.input(Buffer.from(bucket));
}When this is then parsed for negotiations, in input the string is chopped by one character: Line 471 of RanvierTelnet.js:
this.emit('data', cleanbuf.slice(0, cleanlen - 1));
These leaves the emitted result as "Tes"
I'm not sure this is only common to GMud, I believe I had this problem when implementing my own socket library previously. While the newest telnet specification says you should only be parsing CRLF in line mode, it does mention that LF \n alone is questionable (saying prefer not) but that older specifications didn't really call it out. For interoperability on Mud Clients it might be something to consider.
The historical NVT documents do not call out either "bare LF" (LF without CR) or HT for special treatment. Both have generally been understood to be problematic. In the case of LF, there is a difference in interpretation as to whether its semantics imply "go to same position on the next line" or "go to the first position on the next line" and interoperability considerations suggest not depending on which interpretation the receiver applies. At the same time, misinterpretation of LF is less harmful than misinterpretation of "bare" CR: in the CR case, text may be erased or made completely unreadable; in the LF one, the worst consequence is a very funny-looking display. Obviously, HT is problematic because there is no standard way to transmit intended tab position or width information in running text. Again, the harm is unlikely to be great if HT is simply interpreted as one or more spaces, but, in general, it cannot be relied upon to format information.
For accessibility, though, and as I previously said, I do fall into the camp of accepting \n by itself or, if the MUD does not have any specific character-based terminal actions even the stripping of \r completely and processing of \n by itself.
kristianoye
When connecting with certain mud clients (GMud32 for example) the socket code appears to make some assumptions about line-endings. When logging on if I type "limpingninja" it returns: "limpingninj" and in single character selection menus ([y/n] it never gets input) as it appears to be pulling len-2 and probably only getting a single CR or similar. I plan on testing a little today just to see where the failure is, but haven't dug too deeply yet.