Using \r\n on Unix platforms
I am using Java to write a MUD server. The question is the following: Windows programs need the \r in front of the \n. What happpens if a Unix program tries to print \r? I don't want to remove the option of playing the MUD from a computer that is running Unix. Should I just go ahead and always use \r\n or should I ask the client on what platform she/he is and then set some variable that stores the
"newline" string?
On Un*x systems a ^M will be printed.
It is the task of the client to reformat the newline string. Since you should consider string translation anyway (different locale settings, etc.) you could just use \n and expand to \r\n if necessary on the client side.
It is the task of the client to reformat the newline string. Since you should consider string translation anyway (different locale settings, etc.) you could just use \n and expand to \r\n if necessary on the client side.
Obviously it's going to depend on the terminal's mode at the time, but normally a \r is a "carriage return" which moves the cursor to the left-hand column. This is true EVEN on Unix.
The reason that Unix doesn't normally have \r in text files is that there is a software layer (tty layer) which normally automatically generates \r as necessary before a \n (this can be enabled / disabled if you program the unix terminal layer on a low level).
Unix terminals still require \r, and indeed, won't have the expected result without it.
In a worst-case scenario, you would get an extra \r out, which is harmless in any case, you'd end up with \r\r\n at the end of a line.
I suggest that you monitor a Unix telnet session using your favourite network analyser and watch what happens - I would not be surprised if \r is sent by the Unix telnet daemon, at least some of the time.
Originally \n was "linefeed" which made the teletypewriter move the drive on (thus moving to the next line on the paper) and \r was "carriage return" which moved the carriage back to its home position.
For those of you who have never used a typewriter, the paper moves, not the printer. The carriage is the bit that carries the paper and moves it.
Early systems also would automatically spit out a number of NUL characters (\0) after a CR, to make sure that the tty had time to get back to its home position, otherwise the first few characters would be printed part way along the line (in the wrong place) as the carriage was still returning.
This is because teletypewriters (original ones certainly, I've never used one myself!) mechanically directly decoded ascii characters at 75 bits per second, and thus could not buffer the next line's characters until they were ready.
There is no chance that a ^M will be printed normally, this is just added by some editors so that you can see it.
Mark
The reason that Unix doesn't normally have \r in text files is that there is a software layer (tty layer) which normally automatically generates \r as necessary before a \n (this can be enabled / disabled if you program the unix terminal layer on a low level).
Unix terminals still require \r, and indeed, won't have the expected result without it.
In a worst-case scenario, you would get an extra \r out, which is harmless in any case, you'd end up with \r\r\n at the end of a line.
I suggest that you monitor a Unix telnet session using your favourite network analyser and watch what happens - I would not be surprised if \r is sent by the Unix telnet daemon, at least some of the time.
Originally \n was "linefeed" which made the teletypewriter move the drive on (thus moving to the next line on the paper) and \r was "carriage return" which moved the carriage back to its home position.
For those of you who have never used a typewriter, the paper moves, not the printer. The carriage is the bit that carries the paper and moves it.
Early systems also would automatically spit out a number of NUL characters (\0) after a CR, to make sure that the tty had time to get back to its home position, otherwise the first few characters would be printed part way along the line (in the wrong place) as the carriage was still returning.
This is because teletypewriters (original ones certainly, I've never used one myself!) mechanically directly decoded ascii characters at 75 bits per second, and thus could not buffer the next line's characters until they were ready.
There is no chance that a ^M will be printed normally, this is just added by some editors so that you can see it.
Mark
You need to send \r\n over telnet, regardless of what OS the server or client is running on. It should work everywhere, providing a new line starting at column 1 is what you intend.
3.3.1 Telnet End-of-Line Convention
3.3.1 Telnet End-of-Line Convention
Quote: Original post by Kylotan
You need to send \r\n over telnet, regardless of what OS the server or client is running on. It should work everywhere, providing a new line starting at column 1 is what you intend.
3.3.1 Telnet End-of-Line Convention
Thanks a bunch!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement