Path: csiph.com!aioe.org!peer03.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx24.iad.POSTED!not-for-mail From: usenet@only.tnx (Questor) Newsgroups: alt.folklore.computers Subject: Re: CR or LF? Organization: random access Reply-To: usenet@only.tnx Message-ID: <5e9a75a3.856491@news.dslextreme.com> References: X-Newsreader: Forte Free Agent 1.21/32.243 Lines: 54 X-Complaints-To: abuse2@dslextreme.com NNTP-Posting-Date: Sat, 18 Apr 2020 03:40:06 UTC Date: Sat, 18 Apr 2020 03:40:29 GMT X-Received-Bytes: 3978 X-Received-Body-CRC: 1264992956 Xref: csiph.com alt.folklore.computers:211009 "We are the programmers who now terminate our text file lines with ekky-ekky-ekky-ekky-p'tang-zoom-boing!-mrowrrr." -- the programmers who formerly terminated their text file lines with CRLF I've seen "religious" wars over operating systems, languages, and editors, but over text file line terminators? Who would have guessed? Some people in this discussion are conflating printers and terminals, and there is a salient distinction to be made there. Given the context of the times and the number of printing/paper terminals in use then, it is entirely reasonable that text file lines be terminated with a CRLF pair, so that a file that was TYPEd would display correctly on a terminal without any implicit processing by the operating system. As others have noted, it also allows for overstriking. The other appropriate control characters -- tab, vertical tab, form feed (AKA page throw), and bell -- had their expected effect as well. In the days when I was slinging code on PDP10s, it was common practice for programs to accept CR, LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. This behavior was emulated by video terminals (AKA glass ttys). A bare CR would return the cursor to the beginning of the line without moving to the next line; a bare LF would move the cursor to the next line but not horizontally. I relied on this when I wrote a little joke program that would display the lines of a text file from right to left instead of left to right, and it worked on both printing and video terminals. I once had a customer problem that involved line terminators. This user had a COBOL program on a PDP10 (I can't remember if it was TOPS10 or TOPS20, but no matter) that generated a report -- a text file. The file was transfered over DECnet to a VAX, where it would be printed. The problem was that when the file was printed, all the blank line spacing was doubled. If there was supposed to be one blank line there were two, if there was supposed to be two blank lines there were four, etc. I don't know COBOL, but the problem arose due to how the "advancing" clause used in the program's print statements was implemented. The COBOL runtime system would terminate the first line with a CRLF, and then output the appropriate number of bare LFs to create the desired number of blank lines. VMS has what I would call a very aggressive record management system (RMS). When the file was transfered to the VAX, the RMS somehow recognized the LFs as being separate lines, but put them each in their own record. So when the file was printed, it would output the bare LF from the record, and then, because it was a text file and according to the RMS each record in a text file is terminated by a CRLF, it would send that as well. Changing the PDP10 COBOL runtime system was out of the question, as its behavior was long-established and perhaps relied on by other programs. Changing the VMS RMS was also a non-starter. I offered a couple of work-arounds, the details of which are long forgotten. One of them was to use the appropriate VMS command to change the RMS properties of the transferred file. I think there may have also been a switch to NFT (the DECnet Network File Transfer utility) that caused the file to be received by the VAX as a type that would print as desired.