Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!olivea!uunet!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <42014@nigel.ee.udel.edu>
Date: 17 Jan 91 21:49:51 GMT
References: <5293@auspex.auspex.com> <41902@nigel.ee.udel.edu> <5337@auspex.auspex.com>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 127
Nntp-Posting-Host: sam.ee.udel.edu

In article <5337@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>The ability to change a file without invalidating all the hardcopies
>>you may have of the file.
>
>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.  Think about old BASICs where the editor is built in; how did
you number your programs?

>How often, if ever, did you have to "renumber" the lines in a file, say
>because you needed to insert something between two lines with adjacent
>line numbers?

The lines I used had three decimal places; I rarely ran out. I usually
renumbered before making a new, clean listing, which was usually when I
ran out of differnt color pens :-)

>>I never missed line numbers in a system where I would never look at a
>>hardcopy (like Smalltalk).

>I never miss line numbers in a system where I rarely look at hardcopies,
>and even more rarely, if ever, line-number them in any case (like UNIX).

>>Either is fine.  I'm considering lines and records to be the same
>>thing here.
>
>OK, then in *that* case, UNIX *does* support records, to some extent;
>see "fgets()".  (Yeah, it's in "a library"; see my other posting, which
>asks what the difference really is, and why it makes a difference.)

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. 

>I'm assuming *you* saw a difference, because you didn't consider UNIX to
>support "records" in the file system, but it does have a standard
>interface for reading a single line from a file ("fgets()").  

And the fputs() interface for writing a 'record' can change other
records, can write multiple records, can leave a record 'unterminated',
and so on. Also, fgets() only works on text files; reading binary
files with fgets() is error-prone.

>I don't, unless your editor on the system that handles line numbers uses
>some "insert a line" primitive on the file being edited that causes a
>correct line number (one between the line numbers of the lines between
>which the new line is being inserted) to be chosen automatically 

Of course. Just as vi or emacs interprets newline to mean go to the
next line on the screen.

>even in that case, I wouldn't consider that a solution if the
>requirement to manage the file that way imposed restrictions on the view
>it could give me of the file.  

On any filesystem that is not extensible, you have problems with
viewing the files in a different way. UNIX has problems viewing files
in a way that you can change the lengths of lines in the middle of a
file. Record- oriented filesystems have problems viewing files as
bytearrays. I would prefer a filesystem that supports both, or even
better, an active filesystem that supports anything I care to write an
interface for.

>Unless you have such an editor, as far as I can see you need some
>specialized handling; either you need an editor that manages line
>numbers, 

An editor on such a system would naturally handle inserting lines
between other lines without renumbering, just as editors on UNIX treat
\014 as 'end of line' and handle 'preserve-type' functions because they
can't update the middle of a file when you make the change.  Again,
think about old microcomputer BASIC editors. Of course you can insert
lines between other lines. Eventually, you must renumber the lines, but
it does not happen every time you make a change. Using vi under UNIX
can be like using a TeX-like typesetter where you had to give the
numeric citation in the text, and find and renumber them every time
you inserted a citation that came earlier in the bibliography.

>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.

Again, the ideal solution would support both (or all three: numbered,
unnumbered, and stream) types of access (as it did under CP/V).

>(I tend to use EMACSish editors that, to
>a large degree, model the file as one huge character string, treating
>newlines like any other character, which can be inserted or deleted, and
>that let me cut arbitrary substrings of that string without regard to
>line boundaries.)

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.  Lines that had not been changed need
not even be written out if there are keys on the file. If lines were
inserted, they can be given appropriate keys upon saving of the
file.  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. 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. If the editor (or even the
system) dies, all changes I've made so far are saved in the file
and I don't need to do anything magic in the editor to preserve those
changes. If I *want* to be able to back out, the editor can store
just the changes lines (and keys) either in a separate file or
in memory until I chose to apply those changes.

	      -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=