# Thoughts on lines of ASCII text
There are several standards for what constitutes a text file, and
what constitutes a line of text. In POSIX, a text file is an
arbitrary number of lines of text. A line of text is a sequence of
some system defined maximum number of non-line feed characters,
terminated by a line feed character. I often see people complain
that e.g. Microsoft or network protocols have a different idea of
what constitutes a line of text.
To say that this is not entirely unreasonable, one has to consider
the mechanical meaning of a line feed. It just rolls the paper up,
feeding a new line under the type head. In the Microsoft world, the
additional carriage return character represents a different
mechanism, which returns the carriage so that the type head is at
the left margin.
From that perspective it makes sense to represent the end of each
line with both these characters. The order doesn't really matter,
mechanically. Indeed, on old Macs the conventional order was
different from that of DOS.
Additionally, I don't believe that each line of text in a DOS text
file has to be terminated by CR and LF. The last line of text in a
text file is instead terminated by the end of the file. POSIX by
comparison is practical; you can concatenate two text files byte by
byte and be sure that no lines have been joined. You can read a text
file and assume that any line of text ends with a line feed, and
that the line feed is the point at which you can process a whole
line. The end of the file never has to be considered.
So how do you read lines of ASCII text from a text file in a way
that is generally compatible? First, ignore CR characters, just drop
them as they come in. At every line feed consider the text that has
been read since the last line feed or the start of the file as the
content of the line of text. If there are trailing characters after
the last line feed, consider those a line of text as well. Simple,
but ignores more obscure formats of ASCII text files (that for
example terminate lines with only a carriage return).
Strange topic to ramble about, but I find the history interesting
and have always aimed to create robust and forgiving text parsers
because the different conventions are reasonable in different ways.