mcdonald@uxe.cso.uiuc.edu (07/31/89)
>As someone else mentioned n passing, MS-DOS's convention eats up 2K on a >2000-line file, to no advantage. Programs that process input streams >have to do more work to handle End-Of-Lines; not much, but a bit more. >Forgetting compatibility, the Unix convention just makes more sense. No, it doesn't, at least for ASCII. In ascii, carriage return and line feed are separate characters. Ascii terminals require both to get to the left hand side of a new line. Thus, with the MS-DOS convention, a text file is a plain file - no translation is necessary for it to be sent to a terminal. For Unix, text files must be translated so a lf sends out both a line feed and a carriagereturn - and this means it is impossible to send out a linefeed alone. If ascii had a newline character, then everybody would be the same, but it doesn't have that - it has a separate line feed and carriage return. C's use of a single newline indicator is an oddity too. Doug McDonald
ken@cs.rochester.edu (Ken Yap) (08/04/89)
|No, it doesn't, at least for ASCII. In ascii, carriage return and |line feed are separate characters. Ascii terminals require both |to get to the left hand side of a new line. Thus, with the MS-DOS |convention, a text file is a plain file - no translation is necessary |for it to be sent to a terminal. For Unix, text files must be translated |so a lf sends out both a line feed and a carriagereturn - and this |means it is impossible to send out a linefeed alone. | |If ascii had a newline character, then everybody would be the same, |but it doesn't |have that - it has a separate line feed and carriage return. | |C's use of a single newline indicator is an oddity too. Sorry to possibly start a flame war, but the Unix convention makes a lot of sense. To start off, why have outdated notions about what CR and LF do? Those belong to the age of clunky teletypes. What is really needed is a line separator in files. Should it be one character or the CR/LF pair? Why complicate things by using two characters when one will do? One character avoids all questions about what a single LF or a LF/CR pair might mean, as well as making it easy for programs to generate an end of line by sending out one character. Should it be LF or CR? CR is useful for overstriking while LF alone is not useful. So we shouldn't preempt CR. So LF it is. Call it newline. Snag is, terminals have this RETURN key. So do the translation in the terminal driver. It's the only place that needs to translate CR to NL on input and NL to CR/LF on output. Everywhere else NL ('\n') is used. I'm sure either Ken or Dennis went through this argument in their minds when they were designing.
ho@fergvax.unl.edu (Tiny Bubbles...) (08/08/89)
From article <1989Aug4.043051.14636@cs.rochester.edu>, by ken@cs.rochester.edu (Ken Yap): > |If ascii had a newline character, then everybody would be the same, > |but it doesn't > |have that - it has a separate line feed and carriage return. > | > |C's use of a single newline indicator is an oddity too. > > Sorry to possibly start a flame war, but the Unix convention makes a > lot of sense. To start off, why have outdated notions about what CR and > LF do? Those belong to the age of clunky teletypes. What is really I'd like to put a V-8 in my VW Rabbit for some extra get-up-and-go, too. Unfortunately, you have to work with your limitations. DOS evolved from CP/M, with its CRLF and ^Z conventions; as long as DOS is DOS, then those will have to stay. It's one thing to add handle I/O to make DOS seem more like Unix; it's another to make fundamental changes to the file structure. I agree that, theoretically, the \n convention makes more sense /in new installations or operating systems/. But it never makes sense to try to change the structure of an OS without rewriting it and giving it a new name, IMHO. Flame off :-) --- ... Michael Ho, University of Nebraska <ho@fergvax.unl.edu>