Re: wishlist

[culliton@srg.af.mil (Tom Culliton x2278)]

Alan finds a reason why he doesn't need read:

> So, there I was, walking home after work, muttering under my breath,
> and mulling over the analogy between rc having to exec to read a line
> and C having to perform a system call to read a char.  I though I had
> the clincher in this argument.  Then it dawned on me -- we can use
> buffered IO in rc (read many lines with one exec) exactly as we do in C
> (read many chars with one system call).

Strangely enough it was thoughts along this line that that convinced me
that read might be a good idea!  My first thought was that if execing
for each line was too slow why not just do something like this:

	buf = ``($nl) { cat }

And then just step through the list in any of the usual ways.  Of course
the problem is that even rc may not be able to stuff the whole file into
the environment, other programs could choke big time, and it would slow
down forking.  The next step is to get clever and use sed to grab
chunks:

	eof=()
	buf = ``($nl) { sed 20q }
	if (~ $#buf 0) eof = 1;

Of course this is also going to bloat the environment, albeit to a
lesser extent, with the buffer, code to fetch from the buffer and
transparently refill it when it empties, not to mention code to reset
the buffer, etc.  (I may write this up and post it later.)

In shell scripts read is used for two different purposes, getting one
line from a user, or chewing through a theoretically infinite input
stream one line at a time.  In the first case efficiency is usually not
a concern, but in the second case it obviously is.  The fact that the
same generalized facility would serve both cases well, and that these
are fairly common things to do, seem like a good argument for adding
read. (or something like it)

Tom