15 Jun
2020
15 Jun
'20
7:56 p.m.
First, as for pg(1) itself, I thought it came from one of the non-Research
labs, like Holmdel or Indian Hill. I certainly remember using it on AT&T
based system before System V arrived on the scene. It's possible, tjk had
it from USG, but I think it's more likely I saw it from someone like Phil
Karn. We also had pg(1) at Tek until I was introduced to more(1) probably
originally from Jim Kleckner and the CAD folks [which worked better and
pg(1) -- which means I probably brought pg(1) to Tek, unless it came from
one the Purdue folks like Ward, I don't remember]. I also know pg(1)
was available for PWB 3.0 at some point, as we had it at Masscomp before we
got System V and we had it the AT&T 'universe' but I don't remember
the
provenance of that code (again I could have brought it with me, but I think
it came to Masscomp via MIT). That said, Warren's PWB 3.0/SYS III source
tree does not show binary or source, which makes the thought that it was
AT&T based, but originated at a lab other than Summit or MH.
On Mon, Jun 15, 2020 at 1:41 AM Lars Brinkhoff <lars(a)nocrew.org> wrote:
Daniel Halbert wrote to comp.society.folklore in
1994:
"I was a first-year graduate student at UC Berkeley in 1978. I had
been an undergraduate at MIT, and had used the ITS timesharing systems
there, which ran on PDP-10's. ITS put a "--MORE--" at the bottom of
the screen when one typed out files [..]
I believe that to be true.
Wikipedia says "more" was written by Daniel Halbert and expanded by
Eric Shienbrood
and Geoff Peck.
I also believe that is partially true and Mary Ann is actually correct in
the provenance.
I think Eric arrived later than Dan (maybe a year later), but was also
ex-MIT, and he too had used/seen --MORE-- on ITS as Dan had. But I was
under the impression Eric started over. Then a few years after Eric, Geoff
worked with Eric's sources to add a few features. As for starting
over/hacking on the program from Dan's original code base, it's hard to
call that one, as I recall that Dan's version was not much more than a
hack on to cat(1). i.e. the original version was pretty simple, and I don't
remember that it 'knew' about the type of terminal being used, get info
from TERMCAP *et al*. [My intro to Dan's version was at Tek, BTW but was
quickly replaced with Eric's TERMCAP version which I think I got from Mary
Ann, but might have also been via the CAD connection - we in TekLabs had
written all of the TERMCAP support for the Tek 4025 and family and I was
working to get it all back into the UCB database, so we got a bunch of
early PDP-11 based TERMCAP/curses code to help debug things since the 4025
supported some interesting modes].
To be fair, ITS and Dan certainly should get credit for introducing the
idea of the terminal pager to UCB, but it really was Eric that created the
more(1) program framework that took off and eventually did begat less(1),
pg(1), p(1) and others. As for less(1) itself, the Gnu folks seem to
have started with Geoff's version (which I think is the version in 4.2 BSD
if you look at SCCS delta in Kurt's disks), with the biggest addition was
for the user to be able to go backward and look at some of the text that
had already scrolled off the page. But as pointed out elsewhere, after
the Gnu folks had peed all over it; as Doug says, (and I suspect most of us
agree) it really became a sort of lesson in featuritis.
But as discussed on many things in the historical computer world,
more/less/pg/p often comes back to taste -> more(1) and p(1) were much
more directed a doing one job well. As Larry says, there are features of
less(1) which can be handy depending on your environment -- if you don't
have a window manager/BLIT or today's user interfaces with unlimited
scrolling (*i.e. *still on an ADM3A or VT-100), then many of the features
of less(1) probably are considered a nice to have, you got used to them and
it became your standard [burned in the ROMs in your fingers like csh(1) and
vi(1) into my own]. But as Rob and Doug have pointed out, p(1) is more
than sufficient and the 'extras' that programs like less(1) in a modern and
clean environment start having doubtful long term value. Certainly, the
'cost' in complexity and 'code bloat' seems like a poor trade-off.
But the
assumption to me is that the desire for those type of features are
fulfilled with different tools in the current world, but if you grew up
with using them (say like Larry) I can see the value.
Clem