Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <5394@auspex.auspex.com>
Date: 20 Jan 91 22:04:04 GMT
References: <41902@nigel.ee.udel.edu> <5337@auspex.auspex.com> <42014@nigel.ee.udel.edu>
Organization: Auspex Systems, Santa Clara
Lines: 70

>>Which requires that line numbers be something other than simply the
>>ordinal number of the line within the file, as I presume is the case on
>>the systems where you used them.
>
>Wrong assumption.  vi under UNIX will already give me that kind of line
>number. Normally, the line numbers I'm talking about either have decimal
>places or are normally numbered more than one apart, say, every ten or
>hundred.

Umm, then, in that case, exactly as I said, line numbers are something
other than simply the ordinal number of the line within the file; my
presumption appears to be *correct*.  Or did you read me as saying that
I presumed that the line numbers in your files *were* just ordinal
numbers?  Unfortunately, the way I stated it, it could conceivably have
been read either way; sorry if it wasn't clear what I stated.

>Right. To some extent. Which is why most programs consider a newline to
>be the end of a line.  However, I think the real difference between
>'records' and 'lines' as I would use them comes when you want to
>replace a line in the middle of a file with another line of a different
>length. 

In that case, as indicated in another posting, I've never seen a system
where lines are implemented as "records" by your definition; they've all
tended to implement text files as sequential-access files with no keys. 
I presume such systems exist, but I don't know how common they are.

>>the mechanism in some EMACSish editors for running a compile, capturing
>>the error output, parsing it, and walking through the file(s) to which
>
>Which fails to satisfy the hardcopy problem.

So those for whom that's a problem need to use some kind of other
editor.  Lots of us don't really have the hardcopy problem as you
present it....

>You can make a tool to do that in a record-oriented environment as
>easily as you can recognise \014 as an end-of-line character. Just
>read each record into memory, separating them with your desired
>separation character.

Yup, that's probably how EMACS works on systems such as VMS wherein text
files can be sequential files composed of "records" (in a sense other
than yours).

>Of course, using this scheme, you keep the whole file in memory,
>limiting how big your files can get and extending how long it takes to
>make small changes to large files.

A limitation that hasn't been severe for me; I've read some pretty
humongous files with EMACS and not had any horrible problem editing
them.

(Although "vi" doesn't keep the whole file in memory; it uses some other
scheme.  In some sense, you could possibly think of the scheme as
maintaining the file in something vaguely like a keyed file, although
"replacing" a record means "adding it to the end of the file" - it
doesn't bother doing trying to reuse the space for the previous record,
or at least "ed" doesn't and I don't think "ex"/"vi" does either.)

>Sometimes with vi, I want to add "%!PS-Adobe" to the front of a
>postscript file so out printer driver recognises it. A one-line change
>can take several minutes because I have to suck in a multi-megabyte
>file, write it back out to /tmp, make one change, and store it back out
>again, rewriting the file each time, paging like mad. With keyed files,
>I don't even need to read or write anything but the first line.

I guess that seems sufficiently like a sufficiently rare problem to me -
and probably to lots of other people, which may explain why I've never
run into any systems that maintain text files as keyed files.