Format of options file

[Ralph Corderoy]

Hi MacFH,

> nor am I questioning the use of device drivers, obviously they make a
> lot of programming sense.  What I'm questioning is the wisdom, perhaps
> that should be rank stupidity,

You're saying Unix's core designers are stupid for choosing to stick
with text files as lines terminated by LF.  There's some Sherlock Holmes
quote about `It takes talent to recognise genius...'.  :-)

> of using LF as the line-terminator, while treating a preceding CR as
> part of the line text.  That completely f*d backward compatibility
> with what had gone before.

Much of Unix broke orthodoxy, and Unix wasn't the first to punt device
dependencies out of the logical file format and into a device driver
that needed to know about the exceptions and oddities of the physical
world.  Nor was it the first major OS to use LF-terminated lines.

> You say that it is C based, but my recollection of C's internal
> representation is that strings are NULL terminated,

They are, but that it not relevant.

> and that also might have been a more logical choice of line-terminator
> for Unix.

Only if a C string was to be prohibited from holding more than one line
of text.  C allows the bytes "line 1\nline 2\n\0" as a NUL-terminated
string.  And only if a C string "foobar" could no long be split into
two, "foo", "bar", without losing the fact that they are not both lines
that have been read.

C's standard library widely expects LF-terminated lines, and translates,
as I've said twice now in replies to Richard, from the host's
representation to that on reading and back on writing where it differs,
e.g. CP/M and its descendants.

You're drawing conclusions from sketchy knowledge and thus not able to
follow through their implications.  Sorry, but there's no point to this
conversation.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy