"We are the programmers who now terminate our text file lines with
-- 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.