Gregory's Server
@ben not at all, appreciate it -- edited the original post to link to your comment
|
6 comments
 @JeffGrigg @b0rk Yeah it's actually a pretty good way to get a good range of characters and consistency on input from a limited device like a tty or an early terminal. What I had forgotten about (until someone, maybe @cks ? reminded me) is that the driver does similar transformations on output as well.  @JeffGrigg  @JeffGrigg  Mainframes traditionally use fixed-width record sizes to represent "lines." (Or "cards" if you really think their way.) Unix, C, C++ '\n'. (And '^D', not stored in the file, for end of file.) CP/M, MS-DOS, Windows: '\r\n', the physical representation for most "terminals." (And '^Z', in the file, for "end of text in this file." With "junk" to fill the rest of the fixed-size block.) Original Apple Mac: '\r' (or so I've read) PICK OS: hex 'FE' character for line separator The "logical" representation, stored in memory or disk, does not have to correspond exactly to the "physical" representation sent to the terminal/printer. But in CP/M's case, it does simplify things: No translation; just dump text file contents to the console stream, "raw." The implementation of the "TYPE" command is "stream bytes until you hit '^Z' or end of file, and stop." |
@b0rk @ben
Yes, it gets quite "hairy" with "cooked mode" and such.
The interface to ASCII terminals is based on teletypes, where the "Enter" key is "Carriage Return" (^M = 13). On output, to "go to the start of the next line," you need to send "Carriage Return" (^M) and "Line Feed" (^J).
And that's how "new lines" are stored in Windows (from MS-DOS, from CP/M), because CP/M was kind of crude and "dumb."
Unix files use '^J' for "new line." So it has to translate ("cooked mode") on I/O.