Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!dali!uakari.primate.wisc.edu!aplcen!uunet!unhd!unhtel!paul From: paul@unhtel.uucp (Paul S. Sawyer) Newsgroups: comp.unix.questions Subject: Re: Historical question: LF vs. CR\LF in text files Keywords: text files Message-ID: <1990May31.205106.3844@unhtel.uucp> Date: 31 May 90 20:51:06 GMT References: <952@ashton.UUCP> <7581@tekgvs.LABS.TEK.COM> Distribution: usa Organization: UNH Telecommunications and Network Services Lines: 27 In article <7581@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >... >I have used several systems that went the single character route using the >Carriage Return. This is probably the most sensible because input conversion >is not necessary. Also standard typewriter practice is that the carriage >return operation (either key or lever on a manual typewriter (remember those?)) >would also advance the line, but yet line advance could be independently >performed (with the knob on the end of the carriage). > >I know that the net is full of UNIX-myopic people, but UNIX was not first nor >did it make the best move on this one. In the UNIX convention, LF is output as CR/LF, or the printer is set to do CR/LF when it receives a LF; This makes overstriking easy on printers with a limited set of control codes. (e.g., "bold bold bold" or "_________ underline" ) But if CR were translated CR/LF on output, or the printer were to interpret CR as CR/LF, this flexibility is lost. (The printers I'm thinking of do not handle backspacing or reverse index/upline well if at all.) Since these translations are usually transparent to the user, I think UNIX DID do OK on this. (Although I'll admit to the myopia. B-) -- Paul S. Sawyer uunet!unh!unhtel!paul paul@unhtel.UUCP UNH Telecommunications attmail!psawyer p_sawyer@UNHH.BITNET Durham, NH 03824-3523 VOX: +1 603 862 3262 FAX: +1 603 862 2030