* Re: [TUHS] earliest Unix roff
@ 2019-09-15 22:07 Doug McIlroy
2019-09-17 0:20 ` Steve Johnson
0 siblings, 1 reply; 103+ messages in thread
From: Doug McIlroy @ 2019-09-15 22:07 UTC (permalink / raw)
To: tuhs
> Excellent - thanks for the pointer. This shows nroff before troff.
> FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around. i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff. I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.
nroff was in v2; troff appeared in v4, which incidentally was
typeset in troff.
Because of Joe Ossanna's role in designing the model 37, we
had 37's in the Labs and even in our homes right from the
start of production. But when they went obsolete, they were
a chore to get rid of. As Labs property, they had to be
returned; and picking them up was nobody's priority.
Andy Hall had one on his back porch for a year.
Doug
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 22:07 [TUHS] earliest Unix roff Doug McIlroy
@ 2019-09-17 0:20 ` Steve Johnson
2019-09-17 1:11 ` Arthur Krewat
` (2 more replies)
0 siblings, 3 replies; 103+ messages in thread
From: Steve Johnson @ 2019-09-17 0:20 UTC (permalink / raw)
To: Doug McIlroy, tuhs
[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]
Dennis had a model 37 on his sunporch for years. The innards were
nearly all mechanical -- cams and levers, etc. And as the years went
by, wear and tear made the thing shake when it was being used.
From time to time, it would shake so much that a space would be added
into whatever you were typing.
I think Dennis finally retired it after he typed the command "rm
*.o" (a common command in those days of small discs), and got the
respnse ".o not found"
The model37 used fan-fold paper, that we got by the box. It was an
art to arrange the paper flow so that the output didn't pile up inside
the box of blank paper,
but rather ended up in a pile on the floor.
In this era, Unix would, from time to time, crash unexpectedly,
causing you to lose all the edits you hadn't written out yet. The
drill in that case was to
gather up the paper with all your typing on it, and, with a
highlighter, highlight the stuff you needed to retype when the system
came up.
One day I had been furiously editing a long program file for about an
hour and a half when I was called away to lunch, and, being hungry,
didn't save
my file. When I got back to the terminal an hour later, I discovered
two things -- the system had crashed, and our cat had decided that the
pile of paper
on the floor made a great litter box. After a few choice words, I
sighed and picked up my highliter...
Steve
----- Original Message -----
From: "Doug McIlroy" <doug@cs.dartmouth.edu>
To:<tuhs@tuhs.org>
Cc:
Sent:Sun, 15 Sep 2019 18:07:11 -0400
Subject:Re: [TUHS] earliest Unix roff
> Excellent - thanks for the pointer. This shows nroff before troff.
> FWIW: I guess I was miss informed, but I had been under the
impression
> that was the other way around. i.e. nroff was done to be compliant
with
> the new troff, replacing roff, although the suggestion here is that
he
> wrote it add macros to roff. I'll note that either way, the dates
are all
> possible of course because the U/L case ASR 37 was introduced 1968
so by
> the early 1970's they would have been around the labs.
nroff was in v2; troff appeared in v4, which incidentally was
typeset in troff.
Because of Joe Ossanna's role in designing the model 37, we
had 37's in the Labs and even in our homes right from the
start of production. But when they went obsolete, they were
a chore to get rid of. As Labs property, they had to be
returned; and picking them up was nobody's priority.
Andy Hall had one on his back porch for a year.
Doug
[-- Attachment #2: Type: text/html, Size: 3423 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 0:20 ` Steve Johnson
@ 2019-09-17 1:11 ` Arthur Krewat
2019-09-17 1:17 ` Larry McVoy
2019-09-17 1:11 ` [TUHS] Model 37's Ronald Natalie
2019-09-17 1:19 ` [TUHS] earliest Unix roff Bakul Shah
2 siblings, 1 reply; 103+ messages in thread
From: Arthur Krewat @ 2019-09-17 1:11 UTC (permalink / raw)
To: tuhs
On 9/16/2019 8:20 PM, Steve Johnson wrote:
> One day I had been furiously editing a long program file for about an
> hour and a half when I was called away to lunch, and, being hungry,
> didn't save
> my file. When I got back to the terminal an hour later, I discovered
> two things -- the system had crashed, and our cat had decided that the
> pile of paper
> on the floor made a great litter box. After a few choice words, I
> sighed and picked up my highliter...
This should be engraved on a plaque somewhere. Only because I had almost
the same thing happen to me, without the cat though. I had a printout of a
"mail" program I had written on TOPS-10 at high school. I had to retype
the entire thing after the file got corrupted.
Yay MACRO-10
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 1:11 ` Arthur Krewat
@ 2019-09-17 1:17 ` Larry McVoy
2019-09-17 1:26 ` Clem cole
` (2 more replies)
0 siblings, 3 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-17 1:17 UTC (permalink / raw)
To: Arthur Krewat; +Cc: tuhs
On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >One day I had been furiously editing a long program file for about an hour
> >and a half when I was called away to lunch, and, being hungry, didn't save
> >my file.?? When I got back to the terminal an hour later, I discovered two
> >things -- the system had crashed, and our cat had decided that the pile of
> >paper
> >on the floor made a great litter box.?? After a few choice words, I sighed
> >and picked up my highliter...
>
> This should be engraved on a plaque somewhere. Only because I had almost the
> same thing happen to me, without the cat though. I had a printout of a
> "mail" program I had written on TOPS-10 at high school. I had to retype the
> entire thing after the file got corrupted.
I think we have all been there. Something always goes wrong. I wrote
a paper about how to restore a Masscomp because I did rm -rf . in /.
I believe we had roots home as / because /usr was a different partition.
Clem, did Masscomp make roots home / or was that us? Anyway, I did a
cd something
and somehow deleted the something and then did rm -rf .
Much fun was had, I was up all night putting things back together.
This was probably around 1984 or 1985, I was pretty green.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 1:17 ` Larry McVoy
@ 2019-09-17 1:26 ` Clem cole
2019-09-17 1:33 ` Larry McVoy
2019-09-17 1:36 ` Richard Salz
2019-09-17 1:36 ` [TUHS] wizards test [was roff] Clem cole
2019-09-17 1:57 ` [TUHS] earliest Unix roff Bakul Shah
2 siblings, 2 replies; 103+ messages in thread
From: Clem cole @ 2019-09-17 1:26 UTC (permalink / raw)
To: Larry McVoy; +Cc: tuhs
I’ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
>
>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>> One day I had been furiously editing a long program file for about an hour
>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>> things -- the system had crashed, and our cat had decided that the pile of
>>> paper
>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>> and picked up my highliter...
>>
>> This should be engraved on a plaque somewhere. Only because I had almost the
>> same thing happen to me, without the cat though. I had a printout of a
>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>> entire thing after the file got corrupted.
>
> I think we have all been there. Something always goes wrong. I wrote
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us? Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 1:26 ` Clem cole
@ 2019-09-17 1:33 ` Larry McVoy
2019-09-17 22:39 ` Dave Horsfall
2019-09-17 1:36 ` Richard Salz
1 sibling, 1 reply; 103+ messages in thread
From: Larry McVoy @ 2019-09-17 1:33 UTC (permalink / raw)
To: Clem cole; +Cc: tuhs
In retrospect having / be roots home is a super bad idea but I think it
was fairly common practice, /root became a thing as idiots like me
messed things up :)
On Mon, Sep 16, 2019 at 09:26:34PM -0400, Clem cole wrote:
> I???ve forgotten but it could have been early on. Having /root as the super users home directory was on later systems. I thought Masscomp did that but I might be thinking Stellar by then.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> > On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
> >
> >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> >>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >>> One day I had been furiously editing a long program file for about an hour
> >>> and a half when I was called away to lunch, and, being hungry, didn't save
> >>> my file.?? When I got back to the terminal an hour later, I discovered two
> >>> things -- the system had crashed, and our cat had decided that the pile of
> >>> paper
> >>> on the floor made a great litter box.?? After a few choice words, I sighed
> >>> and picked up my highliter...
> >>
> >> This should be engraved on a plaque somewhere. Only because I had almost the
> >> same thing happen to me, without the cat though. I had a printout of a
> >> "mail" program I had written on TOPS-10 at high school. I had to retype the
> >> entire thing after the file got corrupted.
> >
> > I think we have all been there. Something always goes wrong. I wrote
> > a paper about how to restore a Masscomp because I did rm -rf . in /.
> > I believe we had roots home as / because /usr was a different partition.
> > Clem, did Masscomp make roots home / or was that us? Anyway, I did a
> > cd something
> > and somehow deleted the something and then did rm -rf .
> > Much fun was had, I was up all night putting things back together.
> > This was probably around 1984 or 1985, I was pretty green.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 1:33 ` Larry McVoy
@ 2019-09-17 22:39 ` Dave Horsfall
0 siblings, 0 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-17 22:39 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Mon, 16 Sep 2019, Larry McVoy wrote:
> In retrospect having / be roots home is a super bad idea but I think it
> was fairly common practice, /root became a thing as idiots like me
> messed things up :)
After my similar fsckup, I made /etc root's home directory (it was much
easier to recover, and was available at boot time).
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 1:26 ` Clem cole
2019-09-17 1:33 ` Larry McVoy
@ 2019-09-17 1:36 ` Richard Salz
1 sibling, 0 replies; 103+ messages in thread
From: Richard Salz @ 2019-09-17 1:36 UTC (permalink / raw)
To: Clem cole; +Cc: TUHS main list
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
We've all been there. I won a Unix "most egregious use of Unix tools"
award from Usenix for this small script
trap 'ls | wc' 1 2 3 15
echo Reflex test. Type control-c
ls | wc
rm *
Because I also did "rm * .o"
I still have the ugly little warthog, anatomically correct, on my desk.
[-- Attachment #2: Type: text/html, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] wizards test [was roff]
2019-09-17 1:17 ` Larry McVoy
2019-09-17 1:26 ` Clem cole
@ 2019-09-17 1:36 ` Clem cole
2019-09-17 1:38 ` Clem cole
2019-09-17 2:34 ` Larry McVoy
2019-09-17 1:57 ` [TUHS] earliest Unix roff Bakul Shah
2 siblings, 2 replies; 103+ messages in thread
From: Clem cole @ 2019-09-17 1:36 UTC (permalink / raw)
To: Larry McVoy; +Cc: tuhs
Btw. This was some I used as a wizards test.
You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it. You have lost all of bin dev etc and lib by the time he hit ^C. So you have some of /usr inc but much of /usr/bin is still there. No compiler or assembler on the broken machine since that was in bin and lib.
It’s possible to fix it using the other system to help. Just don’t turn the damaged system off 🍺
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
>
>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>> One day I had been furiously editing a long program file for about an hour
>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>> things -- the system had crashed, and our cat had decided that the pile of
>>> paper
>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>> and picked up my highliter...
>>
>> This should be engraved on a plaque somewhere. Only because I had almost the
>> same thing happen to me, without the cat though. I had a printout of a
>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>> entire thing after the file got corrupted.
>
> I think we have all been there. Something always goes wrong. I wrote
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us? Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] wizards test [was roff]
2019-09-17 1:36 ` [TUHS] wizards test [was roff] Clem cole
@ 2019-09-17 1:38 ` Clem cole
2019-09-17 2:34 ` Larry McVoy
1 sibling, 0 replies; 103+ messages in thread
From: Clem cole @ 2019-09-17 1:38 UTC (permalink / raw)
To: Larry McVoy; +Cc: tuhs
I should say you have a root shell on the broken system which why it killed every thing.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Sep 16, 2019, at 9:36 PM, Clem cole <clemc@ccc.com> wrote:
>
> Btw. This was some I used as a wizards test.
>
> You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it. You have lost all of bin dev etc and lib by the time he hit ^C. So you have some of /usr inc but much of /usr/bin is still there. No compiler or assembler on the broken machine since that was in bin and lib.
>
> It’s possible to fix it using the other system to help. Just don’t turn the damaged system off 🍺
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
>>> On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
>>>
>>>> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
>>>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
>>>> One day I had been furiously editing a long program file for about an hour
>>>> and a half when I was called away to lunch, and, being hungry, didn't save
>>>> my file.?? When I got back to the terminal an hour later, I discovered two
>>>> things -- the system had crashed, and our cat had decided that the pile of
>>>> paper
>>>> on the floor made a great litter box.?? After a few choice words, I sighed
>>>> and picked up my highliter...
>>>
>>> This should be engraved on a plaque somewhere. Only because I had almost the
>>> same thing happen to me, without the cat though. I had a printout of a
>>> "mail" program I had written on TOPS-10 at high school. I had to retype the
>>> entire thing after the file got corrupted.
>>
>> I think we have all been there. Something always goes wrong. I wrote
>> a paper about how to restore a Masscomp because I did rm -rf . in /.
>> I believe we had roots home as / because /usr was a different partition.
>> Clem, did Masscomp make roots home / or was that us? Anyway, I did a
>> cd something
>> and somehow deleted the something and then did rm -rf .
>> Much fun was had, I was up all night putting things back together.
>> This was probably around 1984 or 1985, I was pretty green.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] wizards test [was roff]
2019-09-17 1:36 ` [TUHS] wizards test [was roff] Clem cole
2019-09-17 1:38 ` Clem cole
@ 2019-09-17 2:34 ` Larry McVoy
1 sibling, 0 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-17 2:34 UTC (permalink / raw)
To: Clem cole; +Cc: tuhs
That was exactly the situation I had and I had a tough time so I wrote a
little paper about it. Lemme see if I can find it.
Yep, found it. It was when I was messing with roff -me.
http://mcvoy.com/lm/papers/restor.e
http://mcvoy.com/lm/papers/restor.pdf
I was apparently channeling creat(2) because it was too much work for
me (or Ken) to add the trailing e.
I'm sort of impressed that I wrote that in 1985 because I got to undergrad
in 1980, I was an accounting major because my coach in high school was
my accounting teacher, you don't disappoint your coach so I did great at
accounting, got to college, no coach and accounting was *not* my thing,
wandered around for a year or so taking STEM classes, took some Art
History and declared that as a major, did that for 2 years (and got
really good at it, as in I have corrected errors in a textbook about
Greek pottery [1]) only to have my advisor tell me there are no jobs,
so I switched to computer science in 1984. Going from nothing to being
a sys admin that had to do a full restore in a year or so is kinda neat.
But Unix was kinda neat and I was hooked, it's easy to get good when
you really like something (ask me about fly fishing :)
Doug, I still have the nroff/troff/tlb/eqn/pic (sadly no grap but I wrote
my own in pic later) printed out docs that I got from the UW-Madison
Computer Science department. I used those to write that little memo.
[1] A little rant about art and how hard and how easy it can be. You
guys know Picasso? How about Piet Modrian? Most people know both but
don't know that they know Piet. They are very similar, Piet painted
trees, here is one:
http://1.bp.blogspot.com/-KwU6EePgmxk/T8FixzAZxBI/AAAAAAAAB0s/xUKRQc23MNk/s1600/mondrian.jpg
Yep, that's a tree. WTF you say? So all great artist start out doing the
simple stuff. Picasso, if you go back far enough, did still lifes of a
bowl of fruit. Piet did essentially photographs of trees. But then they
get weird, they get more abstract. And more abstract. To the point that
you look at that link above and you go "how is that a tree? That's not a
tree".
You need to see their work in chronological order. You see the stuff
that looks like a photograph and then it is a little different, a little
different, and you get to the end and you go wow, that actually is a tree.
It makes no sense if you just look at one after it gets abstract, it
makes total sense if you see it order.
I had the good fortune to see an exhibit at New Yorks MOMA of Picasso
in chronological order. Holy moly did that snap him into focus.
So that's a very long way of saying that it was easy for me to be good
at Greek pottery because I already knew that if you put someones work
in chronological order it would make sense. The correction I did
that I'm proud of is to Janson's history of art (which is the benchmark
for art history), there was a Greek artist who did a series of pots
and Janson had two pots backwards, the earlier one was the later one.
Janson was dead but the book carried on and they took my fix.
On Mon, Sep 16, 2019 at 09:36:40PM -0400, Clem cole wrote:
> Btw. This was some I used as a wizards test.
>
> You have a working system next to a system that is still running so you have the console and its shell but had the rm -fr / done to it. You have lost all of bin dev etc and lib by the time he hit ^C. So you have some of /usr inc but much of /usr/bin is still there. No compiler or assembler on the broken machine since that was in bin and lib.
>
> It???s possible to fix it using the other system to help. Just don???t turn the damaged system off ????
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
> > On Sep 16, 2019, at 9:17 PM, Larry McVoy <lm@mcvoy.com> wrote:
> >
> >> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> >>> On 9/16/2019 8:20 PM, Steve Johnson wrote:
> >>> One day I had been furiously editing a long program file for about an hour
> >>> and a half when I was called away to lunch, and, being hungry, didn't save
> >>> my file.?? When I got back to the terminal an hour later, I discovered two
> >>> things -- the system had crashed, and our cat had decided that the pile of
> >>> paper
> >>> on the floor made a great litter box.?? After a few choice words, I sighed
> >>> and picked up my highliter...
> >>
> >> This should be engraved on a plaque somewhere. Only because I had almost the
> >> same thing happen to me, without the cat though. I had a printout of a
> >> "mail" program I had written on TOPS-10 at high school. I had to retype the
> >> entire thing after the file got corrupted.
> >
> > I think we have all been there. Something always goes wrong. I wrote
> > a paper about how to restore a Masscomp because I did rm -rf . in /.
> > I believe we had roots home as / because /usr was a different partition.
> > Clem, did Masscomp make roots home / or was that us? Anyway, I did a
> > cd something
> > and somehow deleted the something and then did rm -rf .
> > Much fun was had, I was up all night putting things back together.
> > This was probably around 1984 or 1985, I was pretty green.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 1:17 ` Larry McVoy
2019-09-17 1:26 ` Clem cole
2019-09-17 1:36 ` [TUHS] wizards test [was roff] Clem cole
@ 2019-09-17 1:57 ` Bakul Shah
2 siblings, 0 replies; 103+ messages in thread
From: Bakul Shah @ 2019-09-17 1:57 UTC (permalink / raw)
To: tuhs
On Mon, 16 Sep 2019 18:17:52 -0700 Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Sep 16, 2019 at 09:11:17PM -0400, Arthur Krewat wrote:
> > On 9/16/2019 8:20 PM, Steve Johnson wrote:
> > >One day I had been furiously editing a long program file for about an hour
> > >and a half when I was called away to lunch, and, being hungry, didn't save
> > >my file.?? When I got back to the terminal an hour later, I discovered two
> > >things -- the system had crashed, and our cat had decided that the pile of
> > >paper
> > >on the floor made a great litter box.?? After a few choice words, I sighed
> > >and picked up my highliter...
> >
> > This should be engraved on a plaque somewhere. Only because I had almost th
> e
> > same thing happen to me, without the cat though. I had a printout of a
> > "mail" program I had written on TOPS-10 at high school. I had to retype the
> > entire thing after the file got corrupted.
>
> I think we have all been there. Something always goes wrong. I wrote
> a paper about how to restore a Masscomp because I did rm -rf . in /.
> I believe we had roots home as / because /usr was a different partition.
> Clem, did Masscomp make roots home / or was that us? Anyway, I did a
> cd something
> and somehow deleted the something and then did rm -rf .
> Much fun was had, I was up all night putting things back together.
> This was probably around 1984 or 1985, I was pretty green.
I may have mentioned restoring root directory using peek/poke
commands of a primitive boot loader. Right before Comdex
(fall 1981) someone accidentally wiped out the root dir. IIRC
we had just two systems that actually worked. The other person
was copying the floppy to the second system when something
went wrong. The backup didn't work. And this was a Comdex
special filesystem (with demos for the show painstakingly put
together and no time to recreate it all from scratch). I
happened to remember inode & block numbers of the first few
things so I fixed up the root dir enough for the system to
come up & run fsck. Luckily very little was lost and we were
able to repair the demos and run them at Comdex!
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] Model 37's
2019-09-17 0:20 ` Steve Johnson
2019-09-17 1:11 ` Arthur Krewat
@ 2019-09-17 1:11 ` Ronald Natalie
2019-09-17 1:19 ` [TUHS] earliest Unix roff Bakul Shah
2 siblings, 0 replies; 103+ messages in thread
From: Ronald Natalie @ 2019-09-17 1:11 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Hopkins had a KSR37 in a small office (or perhaps closet) on the second floor. It was also fitted with a modem I built (a Pennywhistle, an absolutely abhorrant design).
It had the greek box and we used it for many a nroff term paper or the like. It was also our way of getting on the Arpanet. The university had a “tie line” that let us call the DC metro area so we could get into the Pentagon TIP. However, Mike Muuss also convinced the operator once to place a collect call. “It’s a computer we are calling,” he told her. “If it beeps, it accepts the charges.” (This was perhaps one of the boldest operator hacks until Brian Redman and Peter Langston were screwing around with a phone switch and programmed it to answer the phone: “Bell Communications Research” (long pause) “Yes, Operator! I’ll accept the charges.”
After I graduated from JHU, I found an ASR 37 in a surplus sale. I had it for years in my apartment kitchen. Not only did it handle all the nroff ESC-8/ESC-9 stuff and the like without need for an output filter, it had a giant NEWLINE key on the right side and was perhaps the only terminal I ever used that didn’t need the unix NL->CRLF mapping turned on. Amusingly, the thing sat there idle until DSR came up on the modem and then its motors would start. When CD came on a bright green PROCEED light illuminated on the front of it. I used it for years until modems got up to the 9600 baud range and decided a CRT would be nicer than the printing terminal.
I gave mine to RS who I think used it to block in someone’s car at one of the nacent long distance data carriers (was either Sprint or MCI).
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 0:20 ` Steve Johnson
2019-09-17 1:11 ` Arthur Krewat
2019-09-17 1:11 ` [TUHS] Model 37's Ronald Natalie
@ 2019-09-17 1:19 ` Bakul Shah
2 siblings, 0 replies; 103+ messages in thread
From: Bakul Shah @ 2019-09-17 1:19 UTC (permalink / raw)
To: Steve Johnson; +Cc: tuhs, Doug McIlroy
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
The one time you didn't want any cat output....
> On Sep 16, 2019, at 5:20 PM, Steve Johnson <scj@yaccman.com> wrote:
>
> One day I had been furiously editing a long program file for about an hour and a half when I was called away to lunch, and, being hungry, didn't save
> my file. When I got back to the terminal an hour later, I discovered two things -- the system had crashed, and our cat had decided that the pile of paper
> on the floor made a great litter box. After a few choice words, I sighed and picked up my highliter...
>
[-- Attachment #2: Type: text/html, Size: 2083 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] [OT] Re: earliest Unix roff
@ 2019-09-19 18:50 Norman Wilson
2019-09-19 19:00 ` Nemo Nusquam
0 siblings, 1 reply; 103+ messages in thread
From: Norman Wilson @ 2019-09-19 18:50 UTC (permalink / raw)
To: tuhs
KatolaZ:
> We can discuss whether the split was necessary or "right" in the first
> instance, as we could discuss whether it was good or not for cat(1) to
> leave Murray Hill in 1979 with no options and come back from Berkley
> with a source code doubled in size and 9 options in 1982.
We needn't discuss that (though of course there are opinions and
mine are the correct ones), but in the interest of historic accuracy,
I should point out by 1979 (V7) cat had developed a single option -u
to turn off stdio buffering.
Sometime before 1984 or so, that option was removed, and cat was
simplified to just
while ((n = read(fd, buf, sizeof(buf))) > 0)
write(1, buf, n)
(error checking elided for clarity)
which worked just fine for the rest of the life of the Research
system.
So it's true that BSD added needless (in my humble but correct
opinion) options, but not that it had none before they touched it.
Unless all those other programs were stuffed into cat in an earlier
Berkeley system, but I don't think they were.
Norman Wilson
Toronto ON
(Three cats, no options)
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] [OT] Re: earliest Unix roff
2019-09-19 18:50 [TUHS] [OT] " Norman Wilson
@ 2019-09-19 19:00 ` Nemo Nusquam
2019-09-19 20:18 ` Larry McVoy
0 siblings, 1 reply; 103+ messages in thread
From: Nemo Nusquam @ 2019-09-19 19:00 UTC (permalink / raw)
To: tuhs
On 09/19/19 14:50, Norman Wilson wrote (in part):
> So it's true that BSD added needless (in my humble but correct
> opinion) options, but not that it had none before they touched it.
> Unless all those other programs were stuffed into cat in an earlier
> Berkeley system, but I don't think they were.
Who said "Cat came back from Berkeley waving flags."?
N.
> Norman Wilson
> Toronto ON
> (Three cats, no options)
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] [OT] Re: earliest Unix roff
2019-09-19 19:00 ` Nemo Nusquam
@ 2019-09-19 20:18 ` Larry McVoy
2019-09-19 20:42 ` [TUHS] " Andy Kosela
0 siblings, 1 reply; 103+ messages in thread
From: Larry McVoy @ 2019-09-19 20:18 UTC (permalink / raw)
To: Nemo Nusquam; +Cc: tuhs
On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
> On 09/19/19 14:50, Norman Wilson wrote (in part):
> >So it's true that BSD added needless (in my humble but correct
> >opinion) options, but not that it had none before they touched it.
> >Unless all those other programs were stuffed into cat in an earlier
> >Berkeley system, but I don't think they were.
>
> Who said "Cat came back from Berkeley waving flags."?
Rob Pike
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 20:18 ` Larry McVoy
@ 2019-09-19 20:42 ` Andy Kosela
0 siblings, 0 replies; 103+ messages in thread
From: Andy Kosela @ 2019-09-19 20:42 UTC (permalink / raw)
To: Larry McVoy; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Thursday, September 19, 2019, Larry McVoy <lm@mcvoy.com> wrote:
> On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
> > On 09/19/19 14:50, Norman Wilson wrote (in part):
> > >So it's true that BSD added needless (in my humble but correct
> > >opinion) options, but not that it had none before they touched it.
> > >Unless all those other programs were stuffed into cat in an earlier
> > >Berkeley system, but I don't think they were.
> >
> > Who said "Cat came back from Berkeley waving flags."?
>
> Rob Pike
>
http://harmful.cat-v.org/cat-v/
--Andy
[-- Attachment #2: Type: text/html, Size: 912 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
@ 2019-09-19 18:42 Norman Wilson
2019-09-19 22:42 ` Rob Pike
0 siblings, 1 reply; 103+ messages in thread
From: Norman Wilson @ 2019-09-19 18:42 UTC (permalink / raw)
To: tuhs
Clem Cole:
Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added to
Unix*. The funny part was that USG thought more(ucb) was a good idea and
then wrote their own, pg(att); which was just as arrogant as the info
behavior from the Gnu folks!!!
======
And others wrote their own too, of course. The one I know
best is p(1), written by Rob Pike in the late 1970s at the
University of Toronto. I encountered at Caltech on the
system Rob had set up before leaving for Bell Labs (and
which I cared for and hacked on for the next four years
before following him). By the time I reached BTL it was
a normal part of the Research system; I believe it's in
all of the Eighth, Ninth, and Tenth Edition manuals.
p is interesting because it's so much lighter-weight, and
because it has rather a different interior design:
Rather than doing termcappy things, p just prints 22 lines
(or the number specified in an option), then doesn't print
the newline after the 22nd line. Hit return and it will
print the next 22 lines, and so on. The resulting text just
flows up the glass-tty screen without any fuss, cbreak, or
anything. (I believe the first version predated V7 and
therefore cbreak.)
Why 22 lines instead of 24, the common height of glass ttys
back then? Partly because that means you keep a line or two
of context when advancing pages, making reading simpler.
But also because in those days, a standard page destined for
a printer (e.g. from pr or nroff, and therefore from man) was
66 lines long. 22 evenly divides 66, so man something | p
never gives you a screen spanning pages.
p was able to back up: type - (and return) instead of just
return, and it reprints the previous 22-line page; -- (return)
the 22 lines before that; and so on. This was implemented
in an interesting and clever way: a wrapper around the standard
I/O library which kept a circular buffer of some fixed number
of characters (8KiB in early versions, I think), and a new
call that, in effect, backed up the file pointer by one character
and returned the character just backed over. That made it easy
to back over the previous N lines: just make that call until
you've seen N newlines, then discard the newline you've just
backed over, and you're at the beginning the first line you want
to reprint.
As I vaguely recall, more was able to back up, but only when
reading from a real file, not a pipeline. p could do (limited
but sufficient) backup from a pipeline too.
As a creature of its pre-window-system era, you could also type
!command when p paused as well.
I remember being quite interested in that wrapper as a
possible library for use in other things, though I never
found a use for it.
I also remember a wonderful Elements-of-Programming-Style
adventure with Rob's code. I discovered it had a bug under some
specific case when read returned less than a full bufferful.
I read the code carefully and couldn't see what was wrong.
So I wrote my own replacement for the problematic subroutine
from scratch, tested it carefully in corner cases, then with
listings of Rob's code and mine side-by-side walked through
each with the problem case and found the bug.
I still carry my own version of p (rewritten from scratch mainly
to make it more portable--Rob's code was old enough to be too
clever in some details) wherever I go; ironically, even back to
U of T where I have been on and off for the past 30 years.
more and less and pg and the like are certainly useful programs;
for various reasons they're not to my taste, but I don't scorn
them. But I can't help being particular fond of p because it
taught me a few things about programming too.
Norman Wilson
Toronto ON
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 18:42 Norman Wilson
@ 2019-09-19 22:42 ` Rob Pike
2019-09-19 22:55 ` Bakul Shah
0 siblings, 1 reply; 103+ messages in thread
From: Rob Pike @ 2019-09-19 22:42 UTC (permalink / raw)
To: Norman Wilson; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 4721 bytes --]
Here is the complete Plan 9 man page for p:
% 9 man p
P(1) P(1)
NAME
p - paginate
SYNOPSIS
p [ -number ] [ file ... ]
DESCRIPTION
P copies its standard input, or the named files if given, to
its standard output, stopping at the end of every 22nd line,
and between files, to wait for a newline from the user. The
option sets the number of lines on a page.
While waiting for a newline, p interprets the commands:
! Pass the rest of the line to the shell as a command.
q Quit.
SOURCE
/usr/local/plan9/src/cmd/p.c
Page 1 Plan 9 (printed 9/20/19)
On Fri, Sep 20, 2019 at 4:43 AM Norman Wilson <norman@oclsc.org> wrote:
> Clem Cole:
>
> Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added
> to
> Unix*. The funny part was that USG thought more(ucb) was a good idea
> and
> then wrote their own, pg(att); which was just as arrogant as the info
> behavior from the Gnu folks!!!
>
> ======
>
> And others wrote their own too, of course. The one I know
> best is p(1), written by Rob Pike in the late 1970s at the
> University of Toronto. I encountered at Caltech on the
> system Rob had set up before leaving for Bell Labs (and
> which I cared for and hacked on for the next four years
> before following him). By the time I reached BTL it was
> a normal part of the Research system; I believe it's in
> all of the Eighth, Ninth, and Tenth Edition manuals.
>
> p is interesting because it's so much lighter-weight, and
> because it has rather a different interior design:
>
> Rather than doing termcappy things, p just prints 22 lines
> (or the number specified in an option), then doesn't print
> the newline after the 22nd line. Hit return and it will
> print the next 22 lines, and so on. The resulting text just
> flows up the glass-tty screen without any fuss, cbreak, or
> anything. (I believe the first version predated V7 and
> therefore cbreak.)
>
> Why 22 lines instead of 24, the common height of glass ttys
> back then? Partly because that means you keep a line or two
> of context when advancing pages, making reading simpler.
> But also because in those days, a standard page destined for
> a printer (e.g. from pr or nroff, and therefore from man) was
> 66 lines long. 22 evenly divides 66, so man something | p
> never gives you a screen spanning pages.
>
> p was able to back up: type - (and return) instead of just
> return, and it reprints the previous 22-line page; -- (return)
> the 22 lines before that; and so on. This was implemented
> in an interesting and clever way: a wrapper around the standard
> I/O library which kept a circular buffer of some fixed number
> of characters (8KiB in early versions, I think), and a new
> call that, in effect, backed up the file pointer by one character
> and returned the character just backed over. That made it easy
> to back over the previous N lines: just make that call until
> you've seen N newlines, then discard the newline you've just
> backed over, and you're at the beginning the first line you want
> to reprint.
>
> As I vaguely recall, more was able to back up, but only when
> reading from a real file, not a pipeline. p could do (limited
> but sufficient) backup from a pipeline too.
>
> As a creature of its pre-window-system era, you could also type
> !command when p paused as well.
>
> I remember being quite interested in that wrapper as a
> possible library for use in other things, though I never
> found a use for it.
>
> I also remember a wonderful Elements-of-Programming-Style
> adventure with Rob's code. I discovered it had a bug under some
> specific case when read returned less than a full bufferful.
> I read the code carefully and couldn't see what was wrong.
> So I wrote my own replacement for the problematic subroutine
> from scratch, tested it carefully in corner cases, then with
> listings of Rob's code and mine side-by-side walked through
> each with the problem case and found the bug.
>
> I still carry my own version of p (rewritten from scratch mainly
> to make it more portable--Rob's code was old enough to be too
> clever in some details) wherever I go; ironically, even back to
> U of T where I have been on and off for the past 30 years.
> more and less and pg and the like are certainly useful programs;
> for various reasons they're not to my taste, but I don't scorn
> them. But I can't help being particular fond of p because it
> taught me a few things about programming too.
>
> Norman Wilson
> Toronto ON
>
[-- Attachment #2: Type: text/html, Size: 14866 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 22:42 ` Rob Pike
@ 2019-09-19 22:55 ` Bakul Shah
0 siblings, 0 replies; 103+ messages in thread
From: Bakul Shah @ 2019-09-19 22:55 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Re: more/less/p
At Fortune Systems Dave Yost added page mode to the tty driver
when his serial io optimizations made scrolling at 9600
blazing fast. He also added an ioctl for page size. By
setting it to something smaller than the tty number of rows
you can see some context as well. This worked pretty well.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
@ 2019-09-19 18:10 Norman Wilson
2019-09-19 18:37 ` Clem Cole
` (2 more replies)
0 siblings, 3 replies; 103+ messages in thread
From: Norman Wilson @ 2019-09-19 18:10 UTC (permalink / raw)
To: tuhs
Larry McVoy:
If you have something like perl that needs a zillion sub pages, info
makes sense. For just a man page, info is horrible.
=====
This pokes me in one of my longest-standing complaints:
Manual entries, as printed by man and once upon a time in
the Programmers' Manual Volume 1, should be concise references.
They are not a place for tutorials or long-winded descriptions
or even long lists of hundreds of options (let alone descriptions
of why the developer thinks this is the neatest thing since
sliced bread and what bread he had in his sandwiches that day).
For many programs, one or two pages of concise reference is
all the documentation that's needed; no one needs a ten-page
tutorial on how to use cat or rm or ls, for example. But some
programs really do deserve a longer treatment, either a tutorial
or an extended reference with more detail or both. Those belong
in separate documents, and are why the Programmers' Manual had
a second volume.
Nowadays people think nothing of writing 68-page-long manual
entries (real example from something I'm working with right now)
that are long, chatty lists of options or configuration-file
directives with tutorial information interspersed. The result
makes the developer feel good--look at all the documentation
I've written!!--but it's useless for someone trying to figure
out how to write a configuration file for the first time, and
not so great even for someone trying to edit an existing one.
Even the Research system didn't always get this right; some
manual entries ran on and on and on when what was really
needed was a concise list of something and a longer accompanying
document. (The Tenth Edition manual was much better about
that, mostly because of all the work Doug put in. I doubt
there has ever been a better editor for technical text than
Doug.) But it's far worse now in most systems, because
there's rarely any editor at all; the manuals are just an
accreted clump.
And that's a shame, though I have no suggestions on how
to fix it.
Norman Wilson
Toronto ON
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 18:10 Norman Wilson
@ 2019-09-19 18:37 ` Clem Cole
2019-09-19 18:44 ` Jon Steinhart
2019-09-19 19:44 ` Steffen Nurpmeso
2019-09-19 20:53 ` Bakul Shah
2 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-19 18:37 UTC (permalink / raw)
To: Norman Wilson; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman@oclsc.org> wrote:
> Manual entries, as printed by man and once upon a time in
> the Programmers' Manual Volume 1, should be concise references.
> They are not a place for tutorials or long-winded descriptions
> or even long lists of hundreds of options (let alone descriptions
> of why the developer thinks this is the neatest thing since
> sliced bread and what bread he had in his sandwiches that day).
>
> For many programs, one or two pages of concise reference is
> all the documentation that's needed; no one needs a ten-page
> tutorial on how to use cat or rm or ls, for example. But some
> programs really do deserve a longer treatment, either a tutorial
> or an extended reference with more detail or both. Those belong
> in separate documents, and are why the Programmers' Manual had
> a second volume.
>
> Nowadays people think nothing of writing 68-page-long manual
> entries (real example from something I'm working with right now)
> that are long, chatty lists of options or configuration-file
> directives with tutorial information interspersed. The result
> makes the developer feel good--look at all the documentation
> I've written!!--but it's useless for someone trying to figure
> out how to write a configuration file for the first time, and
> not so great even for someone trying to edit an existing one.
>
> Even the Research system didn't always get this right; some
> manual entries ran on and on and on when what was really
> needed was a concise list of something and a longer accompanying
> document. (The Tenth Edition manual was much better about
> that, mostly because of all the work Doug put in. I doubt
> there has ever been a better editor for technical text than
> Doug.) But it's far worse now in most systems, because
> there's rarely any editor at all; the manuals are just an
> accreted clump.
>
> And that's a shame, though I have no suggestions on how
> to fix it.
>
> +1
[-- Attachment #2: Type: text/html, Size: 2608 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 18:37 ` Clem Cole
@ 2019-09-19 18:44 ` Jon Steinhart
0 siblings, 0 replies; 103+ messages in thread
From: Jon Steinhart @ 2019-09-19 18:44 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Clem Cole writes:
>
> On Thu, Sep 19, 2019 at 2:11 PM Norman Wilson <norman@oclsc.org> wrote:
>
> > Manual entries, as printed by man and once upon a time in
> > the Programmers' Manual Volume 1, should be concise references.
> > They are not a place for tutorials or long-winded descriptions
> > or even long lists of hundreds of options (let alone descriptions
> > of why the developer thinks this is the neatest thing since
> > sliced bread and what bread he had in his sandwiches that day).
> >
> > For many programs, one or two pages of concise reference is
> > all the documentation that's needed; no one needs a ten-page
> > tutorial on how to use cat or rm or ls, for example. But some
> > programs really do deserve a longer treatment, either a tutorial
> > or an extended reference with more detail or both. Those belong
> > in separate documents, and are why the Programmers' Manual had
> > a second volume.
> >
> > Nowadays people think nothing of writing 68-page-long manual
> > entries (real example from something I'm working with right now)
> > that are long, chatty lists of options or configuration-file
> > directives with tutorial information interspersed. The result
> > makes the developer feel good--look at all the documentation
> > I've written!!--but it's useless for someone trying to figure
> > out how to write a configuration file for the first time, and
> > not so great even for someone trying to edit an existing one.
> >
> > Even the Research system didn't always get this right; some
> > manual entries ran on and on and on when what was really
> > needed was a concise list of something and a longer accompanying
> > document. (The Tenth Edition manual was much better about
> > that, mostly because of all the work Doug put in. I doubt
> > there has ever been a better editor for technical text than
> > Doug.) But it's far worse now in most systems, because
> > there's rarely any editor at all; the manuals are just an
> > accreted clump.
> >
> > And that's a shame, though I have no suggestions on how
> > to fix it.
> >
> > +1
This is sort of my late in life mission. Here's a description of a session
that I've proposed for an upcoming conference.
Once upon a time there was Budweiser. Then, along came craft beer
which started a movement. Now, one can find a whole range of
offerings from craft cheese to artisanal baking soda. Hard to find
is craft programming. What’s called "programming technology" today
seems to be the art of minimizing the damage that can be done by
monkeys at keyboards. Since we can no longer purchase even a
toothpick that doesn’t contain a processor and a blue LED, we depend
on code. How can we revive the art of programming? How do we foster
the creation of good code instead of spending energy minimizing the
damage that can be done by bad code? Our lives depend on it.
My two cents is that craft programmers know how to write good documentation.
Probably one of the things that made BTL so wonderful was the breadth of
knowledge that people had. Ken was recently telling me about Lee McMahon who
was a classically trained monk in addition to writing qsort for V3.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 18:10 Norman Wilson
2019-09-19 18:37 ` Clem Cole
@ 2019-09-19 19:44 ` Steffen Nurpmeso
2019-09-19 20:38 ` John P. Linderman
2019-09-19 20:53 ` Bakul Shah
2 siblings, 1 reply; 103+ messages in thread
From: Steffen Nurpmeso @ 2019-09-19 19:44 UTC (permalink / raw)
To: Norman Wilson; +Cc: tuhs
Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org>:
|Larry McVoy:
|
| If you have something like perl that needs a zillion sub pages, info
| makes sense. For just a man page, info is horrible.
|
|=====
|
|This pokes me in one of my longest-standing complaints:
|
|Manual entries, as printed by man and once upon a time in
|the Programmers' Manual Volume 1, should be concise references.
|They are not a place for tutorials or long-winded descriptions
|or even long lists of hundreds of options (let alone descriptions
|of why the developer thinks this is the neatest thing since
|sliced bread and what bread he had in his sandwiches that day).
|
|For many programs, one or two pages of concise reference is
|all the documentation that's needed; no one needs a ten-page
|tutorial on how to use cat or rm or ls, for example. But some
|programs really do deserve a longer treatment, either a tutorial
|or an extended reference with more detail or both. Those belong
|in separate documents, and are why the Programmers' Manual had
|a second volume.
|
|Nowadays people think nothing of writing 68-page-long manual
|entries (real example from something I'm working with right now)
|that are long, chatty lists of options or configuration-file
|directives with tutorial information interspersed. The result
|makes the developer feel good--look at all the documentation
|I've written!!--but it's useless for someone trying to figure
|out how to write a configuration file for the first time, and
|not so great even for someone trying to edit an existing one.
|
|Even the Research system didn't always get this right; some
I totally disagree with you. Whereas i even admire McIlroy's
"concise", and really love reading Plan9 manual pages, and that
not only because one can imagine _who_ put their fingers on those,
i think manual pages should enable people to work with a program.
And not only intellectual elite, the absolute top of the pops
gathered together in this cave and grooving with a pict, but
"everybody" to the extend possible.
If i would have a lot of money in spare i could hire teams of
three people each which rotate through the develop / test
/ documentation cycle, and around each others work. But that is
not how it goes here, you add a feature and write down the docs,
you extend one and patch in doc where you think it belongs, yet
get infos from someone and patch in doc to clarify something. You
do all that short on time, and finally you have a rag rug.
So what you would need then is time to step back, let time pass,
come back with fresh eyes, reread the entire documentation once,
reflect, and work it all over.
Add the complications of not being a native speaker.
For some projects, add many translations done by volunteers, which
you leave behind if you adhere to this work cycle. (But do not if
you just patch up.)
You could of course split the manual into several subsections, but
which one to split, which not. Duplicate several, for example
command line options, which can initiate complicate tasks, which
need a lengthy text to become understandable?
Who is going to do all that work? Who is the one who will spend
the time and strength necessary to keep all the individual parts
in sync? For example, this week (at least the latter commit) on
FreeBSD the ZFS filesystem, thus a crucial part of the
infrastructure of FreeBSD (no Hammer or BTRFS support), the
i guess second largest free software environment, with quite some
people getting paid for working on the code base, was extended (i
do not use ZFS), but even the help string of the managing tool was
not updated until a follow up commit several days later fixed
that!
So for me this is not feasible. I have the manual, and i have the
help string output for -h / --help, and a longer (long option) one
with --long-help. If you want a quick shot, use -h. If you need
documentation, use the manual.
#?0|kent:mk$ man -l ../nail.1|wc -l
troff: <standard input>:14382: name expected (got '\c'): treated as missing
8172
Without TOC and anchors.
bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).
#?0|kent:mk$ mdoc ../nail.1|wc -l
8307
With TOC and hundreds of internal and external anchors.
#?0|kent:mk$ /tmp/y/s-nail -h|wc -l
24
#?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
57
|manual entries ran on and on and on when what was really
|needed was a concise list of something and a longer accompanying
|document. (The Tenth Edition manual was much better about
|that, mostly because of all the work Doug put in. I doubt
|there has ever been a better editor for technical text than
|Doug.) But it's far worse now in most systems, because
|there's rarely any editor at all; the manuals are just an
|accreted clump.
|
|And that's a shame, though I have no suggestions on how
|to fix it.
I do not know either. The car industry has the many pictures but
no content (for people who spend money), a repair manual for
underpaid mechanics, and detailed spare part foils for those
people working in the dusty spare parts depot. That at least
thirty years ago when i snuffled into that industry.
|Norman Wilson
|Toronto ON
--End of <1568916649.17313.for-standards-violators@oclsc.org>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 19:44 ` Steffen Nurpmeso
@ 2019-09-19 20:38 ` John P. Linderman
2019-09-20 13:41 ` Steffen Nurpmeso
0 siblings, 1 reply; 103+ messages in thread
From: John P. Linderman @ 2019-09-19 20:38 UTC (permalink / raw)
To: Steffen Nurpmeso; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 6093 bytes --]
In the early 70's, Marc Rochkind recommended re-reading the entire UNIX
manual yearly. Back then, it was doable. Now it is probably growing faster
than I can read.
There is a place for a *concise* description of each command, and a
separate place for tutorials and conference papers.
On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org
> >:
> |Larry McVoy:
> |
> | If you have something like perl that needs a zillion sub pages, info
> | makes sense. For just a man page, info is horrible.
> |
> |=====
> |
> |This pokes me in one of my longest-standing complaints:
> |
> |Manual entries, as printed by man and once upon a time in
> |the Programmers' Manual Volume 1, should be concise references.
> |They are not a place for tutorials or long-winded descriptions
> |or even long lists of hundreds of options (let alone descriptions
> |of why the developer thinks this is the neatest thing since
> |sliced bread and what bread he had in his sandwiches that day).
> |
> |For many programs, one or two pages of concise reference is
> |all the documentation that's needed; no one needs a ten-page
> |tutorial on how to use cat or rm or ls, for example. But some
> |programs really do deserve a longer treatment, either a tutorial
> |or an extended reference with more detail or both. Those belong
> |in separate documents, and are why the Programmers' Manual had
> |a second volume.
> |
> |Nowadays people think nothing of writing 68-page-long manual
> |entries (real example from something I'm working with right now)
> |that are long, chatty lists of options or configuration-file
> |directives with tutorial information interspersed. The result
> |makes the developer feel good--look at all the documentation
> |I've written!!--but it's useless for someone trying to figure
> |out how to write a configuration file for the first time, and
> |not so great even for someone trying to edit an existing one.
> |
> |Even the Research system didn't always get this right; some
>
> I totally disagree with you. Whereas i even admire McIlroy's
> "concise", and really love reading Plan9 manual pages, and that
> not only because one can imagine _who_ put their fingers on those,
> i think manual pages should enable people to work with a program.
> And not only intellectual elite, the absolute top of the pops
> gathered together in this cave and grooving with a pict, but
> "everybody" to the extend possible.
>
> If i would have a lot of money in spare i could hire teams of
> three people each which rotate through the develop / test
> / documentation cycle, and around each others work. But that is
> not how it goes here, you add a feature and write down the docs,
> you extend one and patch in doc where you think it belongs, yet
> get infos from someone and patch in doc to clarify something. You
> do all that short on time, and finally you have a rag rug.
>
> So what you would need then is time to step back, let time pass,
> come back with fresh eyes, reread the entire documentation once,
> reflect, and work it all over.
>
> Add the complications of not being a native speaker.
> For some projects, add many translations done by volunteers, which
> you leave behind if you adhere to this work cycle. (But do not if
> you just patch up.)
>
> You could of course split the manual into several subsections, but
> which one to split, which not. Duplicate several, for example
> command line options, which can initiate complicate tasks, which
> need a lengthy text to become understandable?
>
> Who is going to do all that work? Who is the one who will spend
> the time and strength necessary to keep all the individual parts
> in sync? For example, this week (at least the latter commit) on
> FreeBSD the ZFS filesystem, thus a crucial part of the
> infrastructure of FreeBSD (no Hammer or BTRFS support), the
> i guess second largest free software environment, with quite some
> people getting paid for working on the code base, was extended (i
> do not use ZFS), but even the help string of the managing tool was
> not updated until a follow up commit several days later fixed
> that!
>
> So for me this is not feasible. I have the manual, and i have the
> help string output for -h / --help, and a longer (long option) one
> with --long-help. If you want a quick shot, use -h. If you need
> documentation, use the manual.
>
> #?0|kent:mk$ man -l ../nail.1|wc -l
> troff: <standard input>:14382: name expected (got '\c'): treated as
> missing
> 8172
>
> Without TOC and anchors.
> bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).
>
> #?0|kent:mk$ mdoc ../nail.1|wc -l
> 8307
>
> With TOC and hundreds of internal and external anchors.
>
> #?0|kent:mk$ /tmp/y/s-nail -h|wc -l
> 24
> #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
> 57
>
> |manual entries ran on and on and on when what was really
> |needed was a concise list of something and a longer accompanying
> |document. (The Tenth Edition manual was much better about
> |that, mostly because of all the work Doug put in. I doubt
> |there has ever been a better editor for technical text than
> |Doug.) But it's far worse now in most systems, because
> |there's rarely any editor at all; the manuals are just an
> |accreted clump.
> |
> |And that's a shame, though I have no suggestions on how
> |to fix it.
>
> I do not know either. The car industry has the many pictures but
> no content (for people who spend money), a repair manual for
> underpaid mechanics, and detailed spare part foils for those
> people working in the dusty spare parts depot. That at least
> thirty years ago when i snuffled into that industry.
>
> |Norman Wilson
> |Toronto ON
> --End of <1568916649.17313.for-standards-violators@oclsc.org>
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
>
[-- Attachment #2: Type: text/html, Size: 7304 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 20:38 ` John P. Linderman
@ 2019-09-20 13:41 ` Steffen Nurpmeso
2019-09-20 15:03 ` Steffen Nurpmeso
0 siblings, 1 reply; 103+ messages in thread
From: Steffen Nurpmeso @ 2019-09-20 13:41 UTC (permalink / raw)
To: John P. Linderman; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 5605 bytes --]
John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\
zTnDKTg@mail.gmail.com>:
|In the early 70's, Marc Rochkind recommended re-reading the entire \
|UNIX manual yearly. Back then, it was doable. Now it is probably growing \
|faster than I can read.
It is however astonishing by how much even the POSIX standard
changes, as a lowest common denominator. The IETF produces an
overwhelming amount of drafts and RFCs, which need to or should be
adhered to, affecting functionality and documentation. So much
more time would be needed, for so many things.
|There is a place for a concise description of each command, and a separate \
|place for tutorials and conference papers.
Unfortunately not except in FreeBSD and NetBSD, which carry some
in /usr/share/doc, like the BSD mail manual. You need to find it
here, and i wonder how many of those who have grown up in the
Linux world would find them at all. (Or even do a search.)
They are not really updated in addition. Though FreeBSD added
a clang entry, the time when developers invented ideas and
implementations, and documented those under /usr/share/doc are
over even there. This is really sad. Infrequently and getting
rarer i reread those, for example "Rethinking /dev and devices in
the UNIX kernel" about the introduction of devfs, which i still
find great.
It is great to hear you who is responsible that the "load of
options reached 17 in v9", whereas i maintain a fork of the
program which causes "old UNIX hands [to] groan at the monstrous
headers that come from latter-day mailers and at the fatness of
their manuals" (citing A Research UNIX Reader).
To offer a solution i could add another layer in between -h output
and full reference manual, and create a heavily minimized version
of the manual, renaming that one to -reference.1 maybe, and
prominently mention the reference.
Also, easy it is to concisely document that -n chooses a numeric
sort, and -r reverses the result order, but
-b addr, --bcc=..
Send a blind carbon copy to recipient addr.
can result in dead-end or otherwise misunderstood situations
unless you really know that particular manual is stripped down,
and the reference manual makes this
-b addr, --bcc=..
Send a blind carbon copy to recipient addr, if the set[268]ting of
expandaddr[408], one of the INTERNAL VARIABLES[29], allows; the
‘shquote’ expandaddr[408] flag is supported. The option may be
used multiple times. Also see the section On sending mail, and
non-interactive mode[7].
(Here, expandaddr has not been invented by me.)
But if you have the reference a bit present in your head, then
#?0|kent:nail$ .obj/s-nail -h|grep -- -b
[:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:]
. -b, -c, -r, -T, to-addr: ex@am.ple or '(Lovely) Ex <am@p.le>'
should also be sufficient. Blasting the concise complexity of
a mathematical formula,
-a file[=input-charset[#output-charset]], --attach=..
Attach file to the message (for compose mode opportunities refer
to ~@[317] and ~^[319]).
needs to backed as
-a file[=input-charset[#output-charset]], --attach=..
Attach file to the message (for compose mode opportunities refer
to ~@[317] and ~^[319]). Filename transformations[26] (also see
file[193]) will be performed, except that shell variables are not
expanded. Shall file not be accessible but contain a ‘=’ charac‐
ter, then anything before the last ‘=’ will be used as the file‐
name, anything thereafter as a character set specification.
If an input character set is specified, but no output character
set, then the given input character set is fixed as-is, and no
conversion will be applied; giving the empty string or the special
string hyphen-minus ‘-’ will be treated as if ttycharset[590] has
been specified (the default).
If an output character set has also been given then the conversion
will be performed exactly as specified and on-the-fly, not consid‐
ering the file type and content. As an exception the empty string
or hyphen-minus ‘-’, select the default conversion algorithm (see
Character sets[14]): no conversion is performed on-the-fly, file
and its contents will be MIME-classified (HTML mail and MIME
attachments[9], The mime.types files[35]); Only this mode is sup‐
ported without support for character set conversions
(features[411] does not mention ‘+iconv’).
for people to get at least enough of the picture to use the
option. (Note the actual algorithm is documented somewhere else.)
#?0|kent:nail$ .obj/s-nail -h|grep -- '-a '
[:-a attachment:] [:-b bcc-addr:] [:-c cc-addr:]
. -a attachment[=input-charset[#output-charset]]
But normally, all you say is "-a file" and the thing is fine
by default without just doing anything at all. That is how it
should be.
Dear John P. Linderman, be warned that the above output of -b is
new, it was "-[bcrT]:" before, for which to understand regular
expressions or file patterns are implied. I have given you credit
for the change.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
[-- Attachment #2: Original message content --]
[-- Type: message/rfc822, Size: 16687 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 6093 bytes --]
In the early 70's, Marc Rochkind recommended re-reading the entire UNIX
manual yearly. Back then, it was doable. Now it is probably growing faster
than I can read.
There is a place for a *concise* description of each command, and a
separate place for tutorials and conference papers.
On Thu, Sep 19, 2019 at 3:44 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> Norman Wilson wrote in <1568916649.17313.for-standards-violators@oclsc.org
> >:
> |Larry McVoy:
> |
> | If you have something like perl that needs a zillion sub pages, info
> | makes sense. For just a man page, info is horrible.
> |
> |=====
> |
> |This pokes me in one of my longest-standing complaints:
> |
> |Manual entries, as printed by man and once upon a time in
> |the Programmers' Manual Volume 1, should be concise references.
> |They are not a place for tutorials or long-winded descriptions
> |or even long lists of hundreds of options (let alone descriptions
> |of why the developer thinks this is the neatest thing since
> |sliced bread and what bread he had in his sandwiches that day).
> |
> |For many programs, one or two pages of concise reference is
> |all the documentation that's needed; no one needs a ten-page
> |tutorial on how to use cat or rm or ls, for example. But some
> |programs really do deserve a longer treatment, either a tutorial
> |or an extended reference with more detail or both. Those belong
> |in separate documents, and are why the Programmers' Manual had
> |a second volume.
> |
> |Nowadays people think nothing of writing 68-page-long manual
> |entries (real example from something I'm working with right now)
> |that are long, chatty lists of options or configuration-file
> |directives with tutorial information interspersed. The result
> |makes the developer feel good--look at all the documentation
> |I've written!!--but it's useless for someone trying to figure
> |out how to write a configuration file for the first time, and
> |not so great even for someone trying to edit an existing one.
> |
> |Even the Research system didn't always get this right; some
>
> I totally disagree with you. Whereas i even admire McIlroy's
> "concise", and really love reading Plan9 manual pages, and that
> not only because one can imagine _who_ put their fingers on those,
> i think manual pages should enable people to work with a program.
> And not only intellectual elite, the absolute top of the pops
> gathered together in this cave and grooving with a pict, but
> "everybody" to the extend possible.
>
> If i would have a lot of money in spare i could hire teams of
> three people each which rotate through the develop / test
> / documentation cycle, and around each others work. But that is
> not how it goes here, you add a feature and write down the docs,
> you extend one and patch in doc where you think it belongs, yet
> get infos from someone and patch in doc to clarify something. You
> do all that short on time, and finally you have a rag rug.
>
> So what you would need then is time to step back, let time pass,
> come back with fresh eyes, reread the entire documentation once,
> reflect, and work it all over.
>
> Add the complications of not being a native speaker.
> For some projects, add many translations done by volunteers, which
> you leave behind if you adhere to this work cycle. (But do not if
> you just patch up.)
>
> You could of course split the manual into several subsections, but
> which one to split, which not. Duplicate several, for example
> command line options, which can initiate complicate tasks, which
> need a lengthy text to become understandable?
>
> Who is going to do all that work? Who is the one who will spend
> the time and strength necessary to keep all the individual parts
> in sync? For example, this week (at least the latter commit) on
> FreeBSD the ZFS filesystem, thus a crucial part of the
> infrastructure of FreeBSD (no Hammer or BTRFS support), the
> i guess second largest free software environment, with quite some
> people getting paid for working on the code base, was extended (i
> do not use ZFS), but even the help string of the managing tool was
> not updated until a follow up commit several days later fixed
> that!
>
> So for me this is not feasible. I have the manual, and i have the
> help string output for -h / --help, and a longer (long option) one
> with --long-help. If you want a quick shot, use -h. If you need
> documentation, use the manual.
>
> #?0|kent:mk$ man -l ../nail.1|wc -l
> troff: <standard input>:14382: name expected (got '\c'): treated as
> missing
> 8172
>
> Without TOC and anchors.
> bug in groff mdoc macros in 1.22.3, by the way (.Lk i guessed).
>
> #?0|kent:mk$ mdoc ../nail.1|wc -l
> 8307
>
> With TOC and hundreds of internal and external anchors.
>
> #?0|kent:mk$ /tmp/y/s-nail -h|wc -l
> 24
> #?0|kent:mk$ /tmp/y/s-nail --long-help|wc -l
> 57
>
> |manual entries ran on and on and on when what was really
> |needed was a concise list of something and a longer accompanying
> |document. (The Tenth Edition manual was much better about
> |that, mostly because of all the work Doug put in. I doubt
> |there has ever been a better editor for technical text than
> |Doug.) But it's far worse now in most systems, because
> |there's rarely any editor at all; the manuals are just an
> |accreted clump.
> |
> |And that's a shame, though I have no suggestions on how
> |to fix it.
>
> I do not know either. The car industry has the many pictures but
> no content (for people who spend money), a repair manual for
> underpaid mechanics, and detailed spare part foils for those
> people working in the dusty spare parts depot. That at least
> thirty years ago when i snuffled into that industry.
>
> |Norman Wilson
> |Toronto ON
> --End of <1568916649.17313.for-standards-violators@oclsc.org>
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
>
[-- Attachment #2.1.2: Type: text/html, Size: 7304 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-20 13:41 ` Steffen Nurpmeso
@ 2019-09-20 15:03 ` Steffen Nurpmeso
0 siblings, 0 replies; 103+ messages in thread
From: Steffen Nurpmeso @ 2019-09-20 15:03 UTC (permalink / raw)
To: John P. Linderman; +Cc: The Eunuchs Hysterical Society
Steffen Nurpmeso wrote in <20190920134137.DXBTo%steffen@sdaoden.eu>:
|John P. Linderman wrote in <CAC0cEp-CVPb-OhcDHKfbj5nMoiYjkAOEZnEOf4Sv5Zr\
|zTnDKTg@mail.gmail.com>:
...
||There is a place for a concise description of each command, and a \
||separate \
||place for tutorials and conference papers.
...
|Also, easy it is to concisely document that -n chooses a numeric
|sort, and -r reverses the result order, but
|
| -b addr, --bcc=..
| Send a blind carbon copy to recipient addr.
|
|can result in dead-end or otherwise misunderstood situations
|unless you really know that particular manual is stripped down,
|and the reference manual makes this
...
And i want to clarify that we talk about a program which does not
behave the way a user would normally expect, where normally is
that the mail is sent to all recipients.
In an academic or a lab environment you can ask someone, or go
over and say "Hi Ken" or "Hi Kurt", "your program misbehaves".
But in the wild people will simply start to mistrust a program, or
stop using it right away. In 99 percent you will not even get
a bug report or hear just about anything. (Except maybe for the
most popular and widely used programs.) And then all the work,
the blood sweat and tears have been for nothing.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 18:10 Norman Wilson
2019-09-19 18:37 ` Clem Cole
2019-09-19 19:44 ` Steffen Nurpmeso
@ 2019-09-19 20:53 ` Bakul Shah
2 siblings, 0 replies; 103+ messages in thread
From: Bakul Shah @ 2019-09-19 20:53 UTC (permalink / raw)
To: Norman Wilson; +Cc: tuhs
On Sep 19, 2019, at 11:10 AM, Norman Wilson <norman@oclsc.org> wrote:
>
> This pokes me in one of my longest-standing complaints:
>
> Manual entries, as printed by man and once upon a time in
> the Programmers' Manual Volume 1, should be concise references.
> They are not a place for tutorials or long-winded descriptions
> or even long lists of hundreds of options (let alone descriptions
> of why the developer thinks this is the neatest thing since
> sliced bread and what bread he had in his sandwiches that day).
>
> For many programs, one or two pages of concise reference is
> all the documentation that's needed; no one needs a ten-page
> tutorial on how to use cat or rm or ls, for example. But some
> programs really do deserve a longer treatment, either a tutorial
> or an extended reference with more detail or both. Those belong
> in separate documents, and are why the Programmers' Manual had
> a second volume.
>
> Nowadays people think nothing of writing 68-page-long manual
> entries (real example from something I'm working with right now)
> that are long, chatty lists of options or configuration-file
> directives with tutorial information interspersed. The result
> makes the developer feel good--look at all the documentation
> I've written!!--but it's useless for someone trying to figure
> out how to write a configuration file for the first time, and
> not so great even for someone trying to edit an existing one.
>
> Even the Research system didn't always get this right; some
> manual entries ran on and on and on when what was really
> needed was a concise list of something and a longer accompanying
> document. (The Tenth Edition manual was much better about
> that, mostly because of all the work Doug put in. I doubt
> there has ever been a better editor for technical text than
> Doug.) But it's far worse now in most systems, because
> there's rarely any editor at all; the manuals are just an
> accreted clump.
>
> And that's a shame, though I have no suggestions on how
> to fix it.
Agree 100%. But I think what we are really complaining about
is more recent program design & interface. Why do programs
have so many options. Why is their functionality partitioned
better.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
@ 2019-09-15 2:45 Doug McIlroy
0 siblings, 0 replies; 103+ messages in thread
From: Doug McIlroy @ 2019-09-15 2:45 UTC (permalink / raw)
To: tuhs
> I'd love to see the docs on that early stuff and see if Joe Ossanna
> added in his own magic or was he carrying forward earlier magic.
Here are scans of non-unix roff in 1971: https://www.cs.dartmouth.edu/~doug/roff71/roff71
I also have 1969, but it's bedtime and that will have to wait.
Relative numbers (+n), roman numerals, .ti, top and bottom margin settings,
.po, running titles, tab settings, hyphenation and footnotes were not in
Saltzer's runoff. Most other features were.
Doug
^ permalink raw reply [flat|nested] 103+ messages in thread
* [TUHS] My EuroBSDcon talk (preview for commentary)
@ 2019-09-13 3:20 Warner Losh
2019-09-13 19:47 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: Warner Losh @ 2019-09-13 3:20 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
OK. I've shared my slides for the talk.
Some of the family trees are simplified (V7 doesn't have room for all its
ports, for example)
Some of it is a little cheeseball since I'm also trying to be witty and
entertaining (we'll see how that goes).
Please don't share them around until after my talk on the September 20th
I'd like feedback on the bits I got wrong. Or left out. Or if you're in
this and don't want to be, etc.
All the slides after the Questions slide won't be presented and will likely
be deleted.
https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
Please be kind (but if it sucks, please do tell). I've turned on commenting
on the slides. Probably best if you comment there.
I have a video of me giving this talk, but it's too rough to share...
Thanks for any help you can give me.
Warner
[-- Attachment #2: Type: text/html, Size: 1262 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
2019-09-13 3:20 [TUHS] My EuroBSDcon talk (preview for commentary) Warner Losh
@ 2019-09-13 19:47 ` Clem Cole
2019-09-13 20:02 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-13 19:47 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 6113 bytes --]
slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
HP-UP and Tru64 support System V calls.
BTW: DG-UX and Stratus built their own kernels, but used System V command
systems and System Call definitions - which are not listed.
Slide 6 - if you want it I have another picture of the GE system from some
of their literature has a view of all of the components. Send me email if
you want it.
Slide 8 - Sets out to write version of Fortran came up with B. Uses B to
write Assembler
Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version does
not show up until the 1990s with Bob Palmer (and has bad memories for some
of us).
Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
rewrite B compiler to output PDP-11 code.
Slide 18 - B begins to become different enough that Dennis starts to call
it nb [new B], eventually deviates enough to become new language
Slide 19 - 4th Edition release outside of the BTL. Lou Katz becomes 'user
zero'
Slide 20 -- We need to get you the site and group name from Mash. It was
not in Summit, it was not USG - but was in NJ. I thought it was Homdel but
I that is purely speculation.
Also the role of Columbus team needs to be defined. Ask
Mary Ann.
Slide 21 -- I'm not going to argue - but I would ask you to add a
disclaimer. This is what you could reconstruct, but there is some
question of some of the arrows. Heinz might be able to help, but as
Stienhart and I have said, its believed to be in LA; but no one has tracked
him down as he has been pursuing non-computer interests.
Slide 22 --4th Edition went to Katz that this is wrong, who sometimes reads
this mailing list. If not, send me a note, I'll reintroduce you. He might
be able to give you a data. Check with Warren, my >>memory<< is that some
of userland is still in C although a lot assembler is still there.
Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even 100
sites yet. Also there were not "commercial version" this was the first
"commercial license" -- big difference [contact me if you want
explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't
occur until after 7th is released and was a separate license. I would
add, Mike Lesk's portable C library is starting to be used, but most C
program do their own I/O with read/write
First real install man page and Dennis build tape installation
system. Earlier version released as RK05 disk copies.
Also numerous new peripherals. IIRC Support for the 11/40 starts
here, 4th & 5th needed a 45 class, and earlier used the 20 with the CSS MMU.
Slide 24 -- CMU uses it to teaches OS class. makes student in class sign a
sub-license.
Slide 25 - missing the first USENIX tapes. which include Harvard and the
like. Warren and I can probably help a little here.
Slide 26 - new licenses. Commercial license fees change to 20K for 1st
CPU/5K for each CPU afterward. CMU buys first commercial license to use
UNIX to make money [after Cole and Klein go on strike]. Case Western
follows suit 6month later. AT&T agrees for the Universities that they
only had to declare one CPU as commercial and could intermix otherwise and
notifies all the universities that if they were using it for commercial
purposes, then needed a license.
AT&T creates first redistribution license. Needed at least one $20K
commercial CPU and then $150k for the rights to redistribute. Originally
$1K per binary CPU.
Slide 27 -- missing Purdue Dual Vax and CMU Mach
Slide 28 - APS had NH which was the model the DEC plate you show. Maddog
has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
but I don't remember the car -- you can ask him). I have had the
Massachusetts UNIX plate since 1983 (it's on my model S of course). ghg
has indiana from around the same time (I think on a pickup). wnj had the
CA vmunix on his Ferrari, but I don't know if he still has it or what its
on.
Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. Noel
and I can give you the story if you want it. It was on the PDP-11 there.
Joy modified csh and added it to 4.1
Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis create
ENV and it was first distributed in V7.
Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
email for how all this went down or ask Steve yourself.
Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
C) was the default compiler. You are missing a step BTW -- typesetter C
was released between V6 and V7. As is the first draft of the White Book.
The new compiler had stdio but targets V6.
Also mpx was part of DataKit support.
Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships
before Venix. Particularly since you made the comment about System III
The original 8086 Xenix was a pure V7 port, with a few additions Gordon
brought with him from Purdue (i.e. ghg hacks).
Slide 52/53/54/55 -- wrong logo (see above)
On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
> OK. I've shared my slides for the talk.
>
> Some of the family trees are simplified (V7 doesn't have room for all its
> ports, for example)
> Some of it is a little cheeseball since I'm also trying to be witty and
> entertaining (we'll see how that goes).
> Please don't share them around until after my talk on the September 20th
>
> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
> this and don't want to be, etc.
>
> All the slides after the Questions slide won't be presented and will
> likely be deleted.
>
>
> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>
> Please be kind (but if it sucks, please do tell). I've turned on
> commenting on the slides. Probably best if you comment there.
>
> I have a video of me giving this talk, but it's too rough to share...
>
> Thanks for any help you can give me.
>
> Warner
>
[-- Attachment #2: Type: text/html, Size: 12145 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
2019-09-13 19:47 ` Clem Cole
@ 2019-09-13 20:02 ` Clem Cole
2019-09-13 20:06 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-13 20:02 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 7352 bytes --]
BTW: I just thought of something else.... one of the b*tched about the
commercial redistribution license from V7 in 1979, that was not fixed until
the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I
said, a commercial source license was $20K for the first CPU and 5K for
each additional one. Later (System V) it went to $50K for the first and
$10K for each additional. But what really ticked off the vendors like
DEC, Masscomp, Sun et al, was that each system that sources on was supposed
to one of the 'second CPU licenses' - the binary license was not good
enough.
What most of us did, was make sure any system that was a 'source control'
or 'master' system at any 'site' had a full source license, but we were all
in violation of the source agreement on our personal workstations. The
argument was the sources on people's machines was ephemeral and not
'stored' there. But it was definitely contentious.
On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:
> slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
> HP-UP and Tru64 support System V calls.
>
> BTW: DG-UX and Stratus built their own kernels, but used System V command
> systems and System Call definitions - which are not listed.
>
> Slide 6 - if you want it I have another picture of the GE system from some
> of their literature has a view of all of the components. Send me email if
> you want it.
>
> Slide 8 - Sets out to write version of Fortran came up with B. Uses B to
> write Assembler
>
> Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version
> does not show up until the 1990s with Bob Palmer (and has bad memories for
> some of us).
>
> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
> rewrite B compiler to output PDP-11 code.
>
> Slide 18 - B begins to become different enough that Dennis starts to call
> it nb [new B], eventually deviates enough to become new language
>
> Slide 19 - 4th Edition release outside of the BTL. Lou Katz becomes 'user
> zero'
>
> Slide 20 -- We need to get you the site and group name from Mash. It was
> not in Summit, it was not USG - but was in NJ. I thought it was Homdel but
> I that is purely speculation.
> Also the role of Columbus team needs to be defined.
> Ask Mary Ann.
>
> Slide 21 -- I'm not going to argue - but I would ask you to add a
> disclaimer. This is what you could reconstruct, but there is some
> question of some of the arrows. Heinz might be able to help, but as
> Stienhart and I have said, its believed to be in LA; but no one has tracked
> him down as he has been pursuing non-computer interests.
>
> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
> reads this mailing list. If not, send me a note, I'll reintroduce you. He
> might be able to give you a data. Check with Warren, my >>memory<< is that
> some of userland is still in C although a lot assembler is still there.
>
> Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even
> 100 sites yet. Also there were not "commercial version" this was the
> first "commercial license" -- big difference [contact me if you want
> explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't
> occur until after 7th is released and was a separate license. I would
> add, Mike Lesk's portable C library is starting to be used, but most C
> program do their own I/O with read/write
>
> First real install man page and Dennis build tape installation
> system. Earlier version released as RK05 disk copies.
> Also numerous new peripherals. IIRC Support for the 11/40
> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
> CSS MMU.
>
> Slide 24 -- CMU uses it to teaches OS class. makes student in class sign
> a sub-license.
>
> Slide 25 - missing the first USENIX tapes. which include Harvard and the
> like. Warren and I can probably help a little here.
>
> Slide 26 - new licenses. Commercial license fees change to 20K for 1st
> CPU/5K for each CPU afterward. CMU buys first commercial license to use
> UNIX to make money [after Cole and Klein go on strike]. Case Western
> follows suit 6month later. AT&T agrees for the Universities that they
> only had to declare one CPU as commercial and could intermix otherwise and
> notifies all the universities that if they were using it for commercial
> purposes, then needed a license.
>
> AT&T creates first redistribution license. Needed at least one $20K
> commercial CPU and then $150k for the rights to redistribute. Originally
> $1K per binary CPU.
>
> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>
> Slide 28 - APS had NH which was the model the DEC plate you show. Maddog
> has it now on his Jeep when aps moved to CA (he also has the NH Linux plate
> but I don't remember the car -- you can ask him). I have had the
> Massachusetts UNIX plate since 1983 (it's on my model S of course). ghg
> has indiana from around the same time (I think on a pickup). wnj had the
> CA vmunix on his Ferrari, but I don't know if he still has it or what its
> on.
>
> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
>
> Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it. Noel
> and I can give you the story if you want it. It was on the PDP-11 there.
> Joy modified csh and added it to 4.1
>
> Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis create
> ENV and it was first distributed in V7.
>
> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
> email for how all this went down or ask Steve yourself.
>
> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
> C) was the default compiler. You are missing a step BTW -- typesetter C
> was released between V6 and V7. As is the first draft of the White Book.
> The new compiler had stdio but targets V6.
> Also mpx was part of DataKit support.
>
> Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships
> before Venix. Particularly since you made the comment about System III
> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
> brought with him from Purdue (i.e. ghg hacks).
>
> Slide 52/53/54/55 -- wrong logo (see above)
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
>
>> OK. I've shared my slides for the talk.
>>
>> Some of the family trees are simplified (V7 doesn't have room for all its
>> ports, for example)
>> Some of it is a little cheeseball since I'm also trying to be witty and
>> entertaining (we'll see how that goes).
>> Please don't share them around until after my talk on the September 20th
>>
>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>> this and don't want to be, etc.
>>
>> All the slides after the Questions slide won't be presented and will
>> likely be deleted.
>>
>>
>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>
>> Please be kind (but if it sucks, please do tell). I've turned on
>> commenting on the slides. Probably best if you comment there.
>>
>> I have a video of me giving this talk, but it's too rough to share...
>>
>> Thanks for any help you can give me.
>>
>> Warner
>>
>
[-- Attachment #2: Type: text/html, Size: 13922 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
2019-09-13 20:02 ` Clem Cole
@ 2019-09-13 20:06 ` Clem Cole
2019-09-13 20:24 ` Jon Steinhart
0 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-13 20:06 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 8029 bytes --]
Another thought -- the first commercial licensee was Rand. Hired some
former Harvard students who brought UNIX with them. You probably need to
add things like Rand Ports (a.k.a. named pipes) which came from there.
Also Chesson and Co did the original ArpaNET NCP at University of Ill
with some help from the Rand folks. That was done on a V6 system ~ 1978
You also need need Ken's famous V6 'patch' tape -- that 'leaked'
On Fri, Sep 13, 2019 at 4:02 PM Clem Cole <clemc@ccc.com> wrote:
> BTW: I just thought of something else.... one of the b*tched about the
> commercial redistribution license from V7 in 1979, that was not fixed until
> the SVR3 licensing the mid-late 1980s was AT&T's source policy. As I
> said, a commercial source license was $20K for the first CPU and 5K for
> each additional one. Later (System V) it went to $50K for the first and
> $10K for each additional. But what really ticked off the vendors like
> DEC, Masscomp, Sun et al, was that each system that sources on was supposed
> to one of the 'second CPU licenses' - the binary license was not good
> enough.
>
> What most of us did, was make sure any system that was a 'source control'
> or 'master' system at any 'site' had a full source license, but we were all
> in violation of the source agreement on our personal workstations. The
> argument was the sources on people's machines was ephemeral and not
> 'stored' there. But it was definitely contentious.
>
>
>
> On Fri, Sep 13, 2019 at 3:47 PM Clem Cole <clemc@ccc.com> wrote:
>
>> slide 4 -- All of HP-UX, Ultrix and Digital UNIX/Tru64 are BSD kernels.
>> HP-UP and Tru64 support System V calls.
>>
>> BTW: DG-UX and Stratus built their own kernels, but used System V
>> command systems and System Call definitions - which are not listed.
>>
>> Slide 6 - if you want it I have another picture of the GE system from
>> some of their literature has a view of all of the components. Send me
>> email if you want it.
>>
>> Slide 8 - Sets out to write version of Fortran came up with B. Uses B to
>> write Assembler
>>
>> Slide 9 - Wrong DEC logo. Should be the Blue one. The maroon version
>> does not show up until the 1990s with Bob Palmer (and has bad memories for
>> some of us).
>>
>> Slide 17 - Ken write PDP-11 assembler on PDP-7 in B. , Dennis starts to
>> rewrite B compiler to output PDP-11 code.
>>
>> Slide 18 - B begins to become different enough that Dennis starts to call
>> it nb [new B], eventually deviates enough to become new language
>>
>> Slide 19 - 4th Edition release outside of the BTL. Lou Katz
>> becomes 'user zero'
>>
>> Slide 20 -- We need to get you the site and group name from Mash. It was
>> not in Summit, it was not USG - but was in NJ. I thought it was Homdel but
>> I that is purely speculation.
>> Also the role of Columbus team needs to be defined.
>> Ask Mary Ann.
>>
>> Slide 21 -- I'm not going to argue - but I would ask you to add a
>> disclaimer. This is what you could reconstruct, but there is some
>> question of some of the arrows. Heinz might be able to help, but as
>> Stienhart and I have said, its believed to be in LA; but no one has tracked
>> him down as he has been pursuing non-computer interests.
>>
>> Slide 22 --4th Edition went to Katz that this is wrong, who sometimes
>> reads this mailing list. If not, send me a note, I'll reintroduce you. He
>> might be able to give you a data. Check with Warren, my >>memory<< is that
>> some of userland is still in C although a lot assembler is still there.
>>
>> Slide 23 -- ??widespread?? -- I'm not sure I would use that. Not even
>> 100 sites yet. Also there were not "commercial version" this was the
>> first "commercial license" -- big difference [contact me if you want
>> explanation]. IIRC fee was 15K per CPU. Commercial redistribution doesn't
>> occur until after 7th is released and was a separate license. I would
>> add, Mike Lesk's portable C library is starting to be used, but most C
>> program do their own I/O with read/write
>>
>> First real install man page and Dennis build tape installation
>> system. Earlier version released as RK05 disk copies.
>> Also numerous new peripherals. IIRC Support for the 11/40
>> starts here, 4th & 5th needed a 45 class, and earlier used the 20 with the
>> CSS MMU.
>>
>> Slide 24 -- CMU uses it to teaches OS class. makes student in class sign
>> a sub-license.
>>
>> Slide 25 - missing the first USENIX tapes. which include Harvard and the
>> like. Warren and I can probably help a little here.
>>
>> Slide 26 - new licenses. Commercial license fees change to 20K for 1st
>> CPU/5K for each CPU afterward. CMU buys first commercial license to use
>> UNIX to make money [after Cole and Klein go on strike]. Case Western
>> follows suit 6month later. AT&T agrees for the Universities that they
>> only had to declare one CPU as commercial and could intermix otherwise and
>> notifies all the universities that if they were using it for commercial
>> purposes, then needed a license.
>>
>> AT&T creates first redistribution license. Needed at least one $20K
>> commercial CPU and then $150k for the rights to redistribute. Originally
>> $1K per binary CPU.
>>
>> Slide 27 -- missing Purdue Dual Vax and CMU Mach
>>
>> Slide 28 - APS had NH which was the model the DEC plate you show.
>> Maddog has it now on his Jeep when aps moved to CA (he also has the NH
>> Linux plate but I don't remember the car -- you can ask him). I have had
>> the Massachusetts UNIX plate since 1983 (it's on my model S of course).
>> ghg has indiana from around the same time (I think on a pickup). wnj had
>> the CA vmunix on his Ferrari, but I don't know if he still has it or what
>> its on.
>>
>> Slide 29 - Look in HenrySpencer-TUHS.org -- you'll find tail but not head.
>>
>> Slide 31 - Job Control can from Europe via MIT. Jim Kulp wrote it.
>> Noel and I can give you the story if you want it. It was on the PDP-11
>> there. Joy modified csh and added it to 4.1
>>
>> Slide 32 -- JC was not from UCB. Joy got it from MIT -- Dennis create
>> ENV and it was first distributed in V7.
>>
>> Slide 33 -- No Bourne supported ENV in the new shell -- see me earlier
>> email for how all this went down or ask Steve yourself.
>>
>> Slide 34 -- PCC was included, but the Ritchie Compiler (a.k.a. Typesetter
>> C) was the default compiler. You are missing a step BTW -- typesetter C
>> was released between V6 and V7. As is the first draft of the White Book.
>> The new compiler had stdio but targets V6.
>> Also mpx was part of DataKit support.
>>
>> Slide 35 -- Not sure that is true. I thought Microsoft's Xenix ships
>> before Venix. Particularly since you made the comment about System III
>> The original 8086 Xenix was a pure V7 port, with a few additions Gordon
>> brought with him from Purdue (i.e. ghg hacks).
>>
>> Slide 52/53/54/55 -- wrong logo (see above)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 12, 2019 at 11:21 PM Warner Losh <imp@bsdimp.com> wrote:
>>
>>> OK. I've shared my slides for the talk.
>>>
>>> Some of the family trees are simplified (V7 doesn't have room for all
>>> its ports, for example)
>>> Some of it is a little cheeseball since I'm also trying to be witty and
>>> entertaining (we'll see how that goes).
>>> Please don't share them around until after my talk on the September 20th
>>>
>>> I'd like feedback on the bits I got wrong. Or left out. Or if you're in
>>> this and don't want to be, etc.
>>>
>>> All the slides after the Questions slide won't be presented and will
>>> likely be deleted.
>>>
>>>
>>> https://docs.google.com/presentation/d/177KxOif5oHARyIdZHDq-OO67_GVtMkzIAlDX-cHxgb4/edit?usp=sharing
>>>
>>> Please be kind (but if it sucks, please do tell). I've turned on
>>> commenting on the slides. Probably best if you comment there.
>>>
>>> I have a video of me giving this talk, but it's too rough to share...
>>>
>>> Thanks for any help you can give me.
>>>
>>> Warner
>>>
>>
[-- Attachment #2: Type: text/html, Size: 15066 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
2019-09-13 20:06 ` Clem Cole
@ 2019-09-13 20:24 ` Jon Steinhart
2019-09-13 20:43 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: Jon Steinhart @ 2019-09-13 20:24 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Not sure about the last bullet on slide 18. I think that it would be more
correct to say "format" instead of "typeset" since I don't think that the
C/A/T came out until 1972. I guess it all comes down to whether or not you
consider nroff on an ASR-37 to be typesetting.
Jon
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
2019-09-13 20:24 ` Jon Steinhart
@ 2019-09-13 20:43 ` Clem Cole
2019-09-13 20:53 ` Diomidis Spinellis
0 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-13 20:43 UTC (permalink / raw)
To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
Jon - Good catch and that is a good reminder.
Warner - You need to add troff and the C/A/T to your timeline. They were
too important. What I don't remember, although Doug or Steve might, was
the original troff 4th or 5th edition? bwk did ditroff, later with the
addition of the APS5.
FWIW: It was for 6th edition and post 1BSD that Tom Ferin did the original
vcat(1) work at UCSF's PDP-11. It would get spread later to the world as
part of one of the BSDs, but the original emulation of a C/A/T4 with a
plotter support came from Tom, his graphics lab and the earlier work with
the Hershey fonts that CMU and Stanford had done to support the XGP for the
PDP-10s. But that was super important for why people wanted UNIX early on.
On Fri, Sep 13, 2019 at 4:24 PM Jon Steinhart <jon@fourwinds.com> wrote:
> Not sure about the last bullet on slide 18. I think that it would be more
> correct to say "format" instead of "typeset" since I don't think that the
> C/A/T came out until 1972. I guess it all comes down to whether or not you
> consider nroff on an ASR-37 to be typesetting.
>
> Jon
>
[-- Attachment #2: Type: text/html, Size: 1861 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
2019-09-13 20:43 ` Clem Cole
@ 2019-09-13 20:53 ` Diomidis Spinellis
2019-09-13 21:45 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: Diomidis Spinellis @ 2019-09-13 20:53 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
The Fourth Edition manual was typeset in troff:
https://dspinellis.github.io/unix-v4man/v4man.pdf
https://github.com/dspinellis/unix-v4man
The Third Edition was nroff:
https://dspinellis.github.io/unix-v3man/v3man.pdf
https://github.com/dspinellis/unix-v3man
On 13-Sep-19 23:43, Clem Cole wrote:
> Jon - Good catch and that is a good reminder.
> Warner - You need to add troff and the C/A/T to your timeline. They
> were too important. What I don't remember, although Doug or Steve
> might, was the original troff 4th or 5th edition? bwk did
> ditroff, later with the addition of the APS5.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] My EuroBSDcon talk (preview for commentary)
2019-09-13 20:53 ` Diomidis Spinellis
@ 2019-09-13 21:45 ` Clem Cole
2019-09-13 22:13 ` [TUHS] earliest Unix roff Warren Toomey
0 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-13 21:45 UTC (permalink / raw)
To: Diomidis Spinellis; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]
Awesome -- great way to figure it out, although I'm not sure 3rd edition
was nroff, I think it might have been roff. I think a smart test is to
check to see if those sources used a macro package or not. If not macro
package, I think that tells us that the likely formatting program was roff.
It does leave us an interesting question, when did the original roff(1)
show up and when did nroff(1). The original, roff(1), was early, and of
course not until after the original PDP-11/20 port. But was it as early as
first edition? roff was the first formatting program. nroff replaced it
later on, although roff lived through the 6th edition (I do not believe it
is on the v7 tape).
I was under the impression that the order is this ... roff was written for
either v1 or v2 in 1970 or 71; I thought originally by Ken to be similar to
the runoff that ran on the GE systems. At some point the team recieved
the /C/A/T and Joseph Ossanna wrote a new program to support it,
*a.k.a. *troff,
that was similar to roff but troff was not a superset of the original
program. nroff was then written after troff came into being to parrot the
behavior of troff using an ASR-37; but I do not know who was the author (it
might have been Ossanna). But it was a third program, that used the same
macro packages as troff that started to appear for Ossanna's program and
the input language was changed so that a document author could know what
was the output target.
As I said, nroff and roff were in the v6 distribution, although not troff
if I remember it correctly; although troff was part of PWB 1.0. The
inclusion of both roff and nroff was because some of the Unix
papers/documentation used roff for formatting, not the troff/nroff input
syntax. That said, the PWB man pages have the roff manpage, as well as a
single man page for both nroff and troff with sections later that say
'nroff only' and 'troff only.'
Also I do not remember having any macro packages for roff(1), but their
might have been some, although I just checked the PWB man page and it does
not list a .so command to read in macros, there is no mention of a macro
switch on the command line and in the files section the only external file
it used was the hyphenation tables.
Finally, Ossanna tragically died and some time later the new APS/5 was
obtained. So, bwk wrote a new program yet, that used post processors and
some front end tables, to allow the 'typesetter' portion to work regardless
of the output device (*i.e.* device independent troff or ditroff). With
the idea only a single program would be needed to be supported. By this
point nothing in the Research 'releases' required the original roff program
and since it was in assembler, I believe that it was dropped from all
further support.
Clem
On Fri, Sep 13, 2019 at 4:53 PM Diomidis Spinellis <dds@aueb.gr> wrote:
> The Fourth Edition manual was typeset in troff:
> https://dspinellis.github.io/unix-v4man/v4man.pdf
> https://github.com/dspinellis/unix-v4man
>
> The Third Edition was nroff:
> https://dspinellis.github.io/unix-v3man/v3man.pdf
> https://github.com/dspinellis/unix-v3man
>
> On 13-Sep-19 23:43, Clem Cole wrote:
> > Jon - Good catch and that is a good reminder.
> > Warner - You need to add troff and the C/A/T to your timeline. They
> > were too important. What I don't remember, although Doug or Steve
> > might, was the original troff 4th or 5th edition? bwk did
> > ditroff, later with the addition of the APS5.
>
[-- Attachment #2: Type: text/html, Size: 5602 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-13 21:45 ` Clem Cole
@ 2019-09-13 22:13 ` Warren Toomey
2019-09-13 22:55 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: Warren Toomey @ 2019-09-13 22:13 UTC (permalink / raw)
To: tuhs
On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote:
> It does leave us an interesting question, when did the original roff(1)
> show up and when did nroff(1). The original, roff(1), was early, and
> of course not until after the original PDP-11/20 port. But was it as
> early as first edition? roff was the first formatting program. nroff
> replaced it later on, although roff lived through the 6th edition (I do
> not believe it is on the v7 tape).
There was a roff on PDP-7 Unix:
By the spring of 1971, it was generally agreed that no one had the
slightest interest in scrapping Unix. Therefore, we transliterated
the roff text formatter into PDP-11 assembler language, starting from
the PDP-7 version that had been transliterated from McIlroy’s BCPL
version on Multics, which had in turn been inspired by J. Saltzer’s
runoff program on CTSS.
From "The Evolution of the Unix Time-sharing System"
http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf
Cheers, Warren
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-13 22:13 ` [TUHS] earliest Unix roff Warren Toomey
@ 2019-09-13 22:55 ` Clem Cole
2019-09-14 2:02 ` Larry McVoy
0 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-13 22:55 UTC (permalink / raw)
To: Warren Toomey; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Thanks. So we have a date that explains the pdp-11 assembler version - it
was there at v1.
On Fri, Sep 13, 2019 at 6:14 PM Warren Toomey <wkt@tuhs.org> wrote:
> On Fri, Sep 13, 2019 at 05:45:51PM -0400, Clem Cole wrote:
> > It does leave us an interesting question, when did the original
> roff(1)
> > show up and when did nroff(1). The original, roff(1), was early, and
> > of course not until after the original PDP-11/20 port. But was it as
> > early as first edition? roff was the first formatting program.
> nroff
> > replaced it later on, although roff lived through the 6th edition (I
> do
> > not believe it is on the v7 tape).
>
> There was a roff on PDP-7 Unix:
>
> By the spring of 1971, it was generally agreed that no one had the
> slightest interest in scrapping Unix. Therefore, we transliterated
> the roff text formatter into PDP-11 assembler language, starting from
> the PDP-7 version that had been transliterated from McIlroy’s BCPL
> version on Multics, which had in turn been inspired by J. Saltzer’s
> runoff program on CTSS.
>
> From "The Evolution of the Unix Time-sharing System"
>
>
> http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf
>
> Cheers, Warren
>
--
Sent from a handheld expect more typos than usual
[-- Attachment #2: Type: text/html, Size: 1917 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-13 22:55 ` Clem Cole
@ 2019-09-14 2:02 ` Larry McVoy
2019-09-14 2:44 ` Warren Toomey
0 siblings, 1 reply; 103+ messages in thread
From: Larry McVoy @ 2019-09-14 2:02 UTC (permalink / raw)
To: Clem Cole; +Cc: tuhs
> > slightest interest in scrapping Unix. Therefore, we transliterated
> > the roff text formatter into PDP-11 assembler language, starting from
> > the PDP-7 version that had been transliterated from McIlroy???s BCPL
> > version on Multics, which had in turn been inspired by J. Saltzer???s
> > runoff program on CTSS.
As a *roff guy to the core, to this day, I'd love to see any docs on the
Multics version and/or the CTSS version.
Roff has some pretty sophisticated stuff (environments come to mind) that
I think 99.9% of the CS world doesn't understand (sort of like my rant
on SCCS, most people didn't look hard enough to get it. I'm not sure
that I get roff environments to this day but I kinda do).
I'd love to see the docs on that early stuff and see if Joe Ossanna
added in his own magic or was he carrying forward earlier magic.
--lm
P.S. I love this list for this stuff, I'm an old retired guy that
wishes he could have helped birth Unix. Hanging out with the people
who were there is super fun.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-14 2:02 ` Larry McVoy
@ 2019-09-14 2:44 ` Warren Toomey
2019-09-15 2:56 ` U'll Be King of the Stars
2019-09-15 19:27 ` Clem Cole
0 siblings, 2 replies; 103+ messages in thread
From: Warren Toomey @ 2019-09-14 2:44 UTC (permalink / raw)
To: Larry McVoy; +Cc: tuhs
On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
> Roff has some pretty sophisticated stuff (environments come to mind) that
> I think 99.9% of the CS world doesn't understand (sort of like my rant
> on SCCS, most people didn't look hard enough to get it. I'm not sure
> that I get roff environments to this day but I kinda do).
>
> I'd love to see the docs on that early stuff and see if Joe Ossanna
> added in his own magic or was he carrying forward earlier magic.
Here's a good page on the history:
https://manpages.bsd.lv/history.html
> P.S. I love this list for this stuff, I'm an old retired guy that
> wishes he could have helped birth Unix. Hanging out with the people
> who were there is super fun.
Hell yeah to both!
Cheers, Warren
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-14 2:44 ` Warren Toomey
@ 2019-09-15 2:56 ` U'll Be King of the Stars
2019-09-15 6:54 ` arnold
2019-09-15 19:35 ` Clem Cole
2019-09-15 19:27 ` Clem Cole
1 sibling, 2 replies; 103+ messages in thread
From: U'll Be King of the Stars @ 2019-09-15 2:56 UTC (permalink / raw)
To: Warren Toomey, Larry McVoy, tuhs
On 14/09/2019 03:44, Warren Toomey wrote:
> On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
>> Roff has some pretty sophisticated stuff (environments come to mind) that
>> I think 99.9% of the CS world doesn't understand
This thread about *roff echoes something that I have been thinking about
recently.
I've been wondering whether it is possible and worthwhile to use *roff
for complex technical documentation. I've always loved the aesthetic
that books produced using *roff have but there are other reasons too.
As far as _markup_ is concerned we have DocBook for example. I am also
looking into this. (Also, I understand it's not a typesetting system.)
Getting back to *roff, does anybody know if there is a (hopefully rich)
repository of macros, or any other resources, for my use case? (La)TeX
has this but I'd like to try something else. What do people think?
Kind regards,
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 2:56 ` U'll Be King of the Stars
@ 2019-09-15 6:54 ` arnold
2019-09-15 7:01 ` Dave Horsfall
` (2 more replies)
2019-09-15 19:35 ` Clem Cole
1 sibling, 3 replies; 103+ messages in thread
From: arnold @ 2019-09-15 6:54 UTC (permalink / raw)
To: wkt, ullbeking, tuhs, lm
"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:
> On 14/09/2019 03:44, Warren Toomey wrote:
> > On Fri, Sep 13, 2019 at 07:02:40PM -0700, Larry McVoy wrote:
> >> Roff has some pretty sophisticated stuff (environments come to mind) that
> >> I think 99.9% of the CS world doesn't understand
>
> This thread about *roff echoes something that I have been thinking about
> recently.
>
> I've been wondering whether it is possible and worthwhile to use *roff
> for complex technical documentation. I've always loved the aesthetic
> that books produced using *roff have but there are other reasons too.
>
> As far as _markup_ is concerned we have DocBook for example. I am also
> looking into this. (Also, I understand it's not a typesetting system.)
Unless you use a WYSIWYG tool that generates DocBook, you should avoid it.
Your fingers will kill you. I have written books in troff, DocBook
and Texinfo. Texinfo is *by far* the superior markup language.
Using Texinfo can generate DocBook which your publisher can turn into PDF.
(I have done this, three times at least.) But working directly in
DocBook just plain hurts.
> Getting back to *roff, does anybody know if there is a (hopefully rich)
> repository of macros, or any other resources, for my use case? (La)TeX
> has this but I'd like to try something else. What do people think?
The MM macros are the most capable of the standard sets that are
out there, although possibly the MOM macros distributed with groff
are even more so; I have not investigated fully.
My own wish for the next genie in a lamp that I come across would be
for a texinfo --> troff translator.
Arnold
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 6:54 ` arnold
@ 2019-09-15 7:01 ` Dave Horsfall
2019-09-15 16:17 ` Jon Steinhart
2019-09-15 19:48 ` Clem Cole
2019-09-15 7:32 ` U'll Be King of the Stars
2019-09-15 19:37 ` Clem Cole
2 siblings, 2 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-15 7:01 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Sun, 15 Sep 2019, arnold@skeeve.com wrote:
> The MM macros are the most capable of the standard sets that are out
> there, although possibly the MOM macros distributed with groff are even
> more so; I have not investigated fully.
For some reason I prefer the MS macros, probably because I learnt them
first and I find it difficult to use MM.
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 7:01 ` Dave Horsfall
@ 2019-09-15 16:17 ` Jon Steinhart
2019-09-15 17:23 ` Ronald Natalie
2019-09-15 19:48 ` Clem Cole
1 sibling, 1 reply; 103+ messages in thread
From: Jon Steinhart @ 2019-09-15 16:17 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Dave Horsfall writes:
> On Sun, 15 Sep 2019, arnold@skeeve.com wrote:
>
> > The MM macros are the most capable of the standard sets that are out
> > there, although possibly the MOM macros distributed with groff are even
> > more so; I have not investigated fully.
>
> For some reason I prefer the MS macros, probably because I learnt them
> first and I find it difficult to use MM.
>
> -- Dave
I am also a MS fan. Tektronix did their own version of MS that added a ton
of really nice features. Would be nice if someone could share that since
Tek is long gone and probably doesn't care.
Jon
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 16:17 ` Jon Steinhart
@ 2019-09-15 17:23 ` Ronald Natalie
0 siblings, 0 replies; 103+ messages in thread
From: Ronald Natalie @ 2019-09-15 17:23 UTC (permalink / raw)
To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society
ROFF is the simplest of the runoff programs but is utterly frozen.
I started with the -ms macro package so I had fondness for it, but switched to -mm over time. I had done some work (after not being able to pry a version Dennis Mumaugh had written out of the agency) on putting classification marking and formatting in it. I had restyled it to make the output look like the standard IBM formatting when we were doing UNIX work under contract for IBM.
At Hopkins, we had a small furor when Mike (Michael John) Muuss wrote his own macro package and installed it as tmac.jm (invoked by the -mjm option). This led to lots of jokes about renaming programs and options after various users.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 7:01 ` Dave Horsfall
2019-09-15 16:17 ` Jon Steinhart
@ 2019-09-15 19:48 ` Clem Cole
2019-09-15 21:16 ` Dave Horsfall
1 sibling, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-15 19:48 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
I learn runoff from the IBM and the TOPS, then PUB then Scribe before I saw
the nroff/troff family.
I have fond memories of using Scribe (which was sort of the model for the
LaTex macros when it got tied up in the legal entanglements of CMU). So
UNIX was what I had and became adept at it.
Like Larry, it's still my goto today and even prefer to Word for anything
over a single page.
On Sun, Sep 15, 2019 at 3:01 AM Dave Horsfall <dave@horsfall.org> wrote:
> For some reason I prefer the MS macros, probably because I learnt them
> first and I find it difficult to use MM.
>
The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek}, -me
{UCB}, -mS {MSCP}, -man {UCB version}. I feel into -ms with a couple of
macros from -mS (.Li/Le for lists which were similar to MM's) for big
documents, and the UCB -man for really simple things. It becomes a 'less
is more' sort of thing - -mm and too complicated and I was not writing BTL
tech memos, and after I did not my thesis, I did not need Eric's work
(which was perfect for a UCB thesis).
[-- Attachment #2: Type: text/html, Size: 1815 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 19:48 ` Clem Cole
@ 2019-09-15 21:16 ` Dave Horsfall
0 siblings, 0 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-15 21:16 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Sun, 15 Sep 2019, Clem Cole wrote:
> The order I learned them was -mm {PWB}, -ms {V7}, -man {V7}, -ms {Tek},
> -me {UCB}, -mS {MSCP}, -man {UCB version}. I feel into -ms with a
> couple of macros from -mS (.Li/Le for lists which were similar to MM's)
> for big documents, and the UCB -man for really simple things. It
> becomes a 'less is more' sort of thing - -mm and too complicated and I
> was not writing BTL tech memos, and after I did not my thesis, I did not
> need Eric's work (which was perfect for a UCB thesis).
For me it was ROFF (V5), -man (V6), -ms (V6). These days I don't need
markup any more; the most complicated things I write are letters using
TextEdit on the Mac, and C/Perl/etc with VI :-)
Actually on the odd occasion I need markup it's "groff -ms -Tps" on
the FreeBSD box.
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 6:54 ` arnold
2019-09-15 7:01 ` Dave Horsfall
@ 2019-09-15 7:32 ` U'll Be King of the Stars
2019-09-15 7:46 ` arnold
2019-09-15 19:37 ` Clem Cole
2 siblings, 1 reply; 103+ messages in thread
From: U'll Be King of the Stars @ 2019-09-15 7:32 UTC (permalink / raw)
To: arnold, Warren Toomey, The Eunuchs Hysterical Society, Larry McVoy
On 15/09/2019 07:54, arnold@skeeve.com wrote:
> "U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:
>> I've been wondering whether it is possible and worthwhile to use *roff
>> for complex technical documentation. I've always loved the aesthetic
>> that books produced using *roff have but there are other reasons too.
>>
>> As far as _markup_ is concerned we have DocBook for example. I am also
>> looking into this. (Also, I understand it's not a typesetting system.)
>
> Unless you use a WYSIWYG tool that generates DocBook, you should avoid it.
> Your fingers will kill you.
Oh, I'm not looking for WYSIWIG or even really WYSIMIM. I'm well used
to writing in structural markup and presentation markup languages, e.g.,
LaTeX (which I think is extremely complicated, and since I left the
university environment I do not miss it).
AS for authoring DocBook I was depending on GNU Emacs to do a lot of the
heavy XML stuff for me. Wishful thinking perhaps.
> I have written books in troff, DocBook
> and Texinfo. Texinfo is *by far* the superior markup language.
I've had a feeling that Texinfo has been getting brushed to the side.
Are you suggesting that Info is a good as a rendered documentation
format? Or just that Texinfo is good for proto-documents that are to be
authored in a parseable and meaningful format?
I've been a long-time GNU Emacs user so reading Info files is OK for me.
But we've never had a _nice_ Info reader, which is why it didn't take
off I think. A lot of people REALLY hate the Info UI.
Moreover it was (is?) very difficult to generate good contents and index
pages with the official tools that I used at the time. I started
working on improving this about 20 years ago but back then it felt as
though the GNU Info and GNU Emacs projects had other things on their minds.
> Using Texinfo can generate DocBook which your publisher can turn into PDF.
> (I have done this, three times at least.) But working directly in
> DocBook just plain hurts.
OK, so you are suggesting Texinfo as a prototypical markup language, not
necessarily something that will end up as Info files?
I have read the Texinfo documentation and I agree that it seemed like a
rich markup language.
>> Getting back to *roff, does anybody know if there is a (hopefully rich)
>> repository of macros, or any other resources, for my use case? (La)TeX
>> has this but I'd like to try something else. What do people think?
>
> The MM macros are the most capable of the standard sets that are
> out there, although possibly the MOM macros distributed with groff
> are even more so; I have not investigated fully.
Thank you for the heads up. I never heard of MOM but MM is more familiar.
*I haven't really looked at eqn beyond browsing docs and I'm not sure
how much I should expect from it.*
TeX is (still?) the king of mathematical expression typesetting.
> My own wish for the next genie in a lamp that I come across would be
> for a texinfo --> troff translator.
Have you looked at Pandoc? I don't know if it will do this but it's
worth checking out.
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 7:32 ` U'll Be King of the Stars
@ 2019-09-15 7:46 ` arnold
0 siblings, 0 replies; 103+ messages in thread
From: arnold @ 2019-09-15 7:46 UTC (permalink / raw)
To: wkt, ullbeking, tuhs, lm, arnold
Hi.
"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:
> AS for authoring DocBook I was depending on GNU Emacs to do a lot of the
> heavy XML stuff for me. Wishful thinking perhaps.
Possibly. I use gvim. :-) And, no, I won't start _that_ discussion.
To each his own, live and let live.
> > I have written books in troff, DocBook
> > and Texinfo. Texinfo is *by far* the superior markup language.
>
> I've had a feeling that Texinfo has been getting brushed to the side.
It is actively maintained and developed.
> Are you suggesting that Info is a good as a rendered documentation
> format? Or just that Texinfo is good for proto-documents that are to be
> authored in a parseable and meaningful format?
The latter.
> Moreover it was (is?) very difficult to generate good contents and index
> pages with the official tools that I used at the time.
For _printed_ matter, the current texinfo does fine at table of
contents. The upcoming version of texinfo (in prerelease now) has
new indexing capabilities that bring it on par with what you see
in commercial publishing: multilevel indexing, as well as "see" and
"see also" entries.
I agree that Info isn't lovely; I prefer to read the generated HTML
from makeinfo, or the PDF from texi2pdf.
> I have read the Texinfo documentation and I agree that it seemed like a
> rich markup language.
Much of the growth in the markup language has been at my urging
over the years. :-)
> *I haven't really looked at eqn beyond browsing docs and I'm not sure
> how much I should expect from it.*
eqn is the inspiration for math mode in TeX. That's very clear,
and Knuth was also aware of tbl.
> > My own wish for the next genie in a lamp that I come across would be
> > for a texinfo --> troff translator.
>
> Have you looked at Pandoc? I don't know if it will do this but it's
> worth checking out.
Thanks for that pointer. I'll have to take a look at it.
Arnold
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 6:54 ` arnold
2019-09-15 7:01 ` Dave Horsfall
2019-09-15 7:32 ` U'll Be King of the Stars
@ 2019-09-15 19:37 ` Clem Cole
2019-09-16 5:52 ` arnold
2 siblings, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-15 19:37 UTC (permalink / raw)
To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
On Sun, Sep 15, 2019 at 2:55 AM <arnold@skeeve.com> wrote:
> Texinfo is *by far* the superior markup language.
>
I'll take your work for it, but my complaint is it requires emacs to use as
the pager on my screen. If you live in emacs, that makes sense; but most
people, even in the GNU/Linux world, don't.
[-- Attachment #2: Type: text/html, Size: 794 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 19:37 ` Clem Cole
@ 2019-09-16 5:52 ` arnold
2019-09-16 12:10 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: arnold @ 2019-09-16 5:52 UTC (permalink / raw)
To: clemc, arnold; +Cc: tuhs
Clem Cole <clemc@ccc.com> wrote:
> On Sun, Sep 15, 2019 at 2:55 AM <arnold@skeeve.com> wrote:
>
> > Texinfo is *by far* the superior markup language.
> >
> I'll take your work for it, but my complaint is it requires emacs to use as
> the pager on my screen. If you live in emacs, that makes sense; but most
> people, even in the GNU/Linux world, don't.
Not true at all. I don't use Emacs, never have, and likely never will.
I use the standalone Info reader (named info) if I want to look at the
Info output. But as I mentioned already, I usually look at the Texinfo
documentation I'm working on via PDF or HTML.
And gvim has very nice syntax highlighting for Texinfo input files.
Arnold
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 5:52 ` arnold
@ 2019-09-16 12:10 ` Clem Cole
2019-09-16 12:26 ` Lars Brinkhoff
` (4 more replies)
0 siblings, 5 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-16 12:10 UTC (permalink / raw)
To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> I use the standalone Info reader (named info) if I want to look at the
> Info output.
>
Fair enough, but be careful, while I admit I have not looked in a while,
info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
Every time I have tried to deal with it, I have unprogram my fingers and
reset them to emacs.
If it would have used more(1) [or even less(1)] then I would not be as
annoyed.
Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
need to replace them with ITS-like programs.
[-- Attachment #2: Type: text/html, Size: 1538 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:10 ` Clem Cole
@ 2019-09-16 12:26 ` Lars Brinkhoff
2019-09-16 13:42 ` Clem Cole
2019-09-16 13:13 ` Chet Ramey
` (3 subsequent siblings)
4 siblings, 1 reply; 103+ messages in thread
From: Lars Brinkhoff @ 2019-09-16 12:26 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
Clem Cole wrote:
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> the need to replace them with ITS-like programs.
Emacs and Info are rather blatantly are not anywhere near the Unix
philosophy. (Maybe they can be useful anyway.)
However, please note that more(1) also was inspired by, almost copied
from, ITS. Certainly the prompt --More-- is.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:26 ` Lars Brinkhoff
@ 2019-09-16 13:42 ` Clem Cole
2019-09-16 14:54 ` Larry McVoy
` (2 more replies)
0 siblings, 3 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-16 13:42 UTC (permalink / raw)
To: Lars Brinkhoff; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]
On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars@nocrew.org> wrote:
> However, please note that more(1) also was inspired by, almost copied
> from, ITS. Certainly the prompt --More-- is.
>
Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood,
wrote it. He was a MIT undergrad. And Eric happily said it was modeled
from ITS.
And before, Eric wrote it, UNIX lacked anything like it. Which to me is
fine, t*aking an idea from another system to add a new feature that is
lacking.*
What irks me is the blatant force-feeding of any system to the users, be it
ITS, UNIX or Windows into another. It's ok to offer an alternative
interface, but when the system has a mechanism, your tools need to be *socially
compliant* with it, not try to make 'those users become like me.'
Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to
rule).
BTW: If it makes you feel better, I've been fighting this attitude at a
number of places, particularly Intel, for years. For instance, our dev
tools folks wrote their own Installer 'because it was easier for them and
they could use it everywhere'). That's a no-no. If you have Windows
product, you must use Microsoft's installer, if you have a Mac, you use
what Apple gives you, if you have VMS, you used the (wretched) setld, or in
this case, for Linux its rpm/yum et al.; etc. But they had their own
'installer group' and it was easier for >>them<< than for the users.
I think the rule of 'least astonishment' is what needs to be the high order
bit when building tools for people. Again, offering emacs (or any other
ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac
et.. it needs to behave itself with the rest of the system, particularly if
there is already a mechanism in place to do a support function.
Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to
created man pages (or Windows / Mac help). But having a man page that
basically says, see figure one
<https://www.dourish.com/goodies/see-figure-1.html> is not cool.
my 2 cents from a grumpy old guy....
Clem
[-- Attachment #2: Type: text/html, Size: 4208 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 13:42 ` Clem Cole
@ 2019-09-16 14:54 ` Larry McVoy
2019-09-16 16:09 ` Paul Winalski
2019-09-16 22:05 ` Dave Horsfall
2 siblings, 0 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 14:54 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
Holy smokes, Clem, you are me and I am you. I couldn't agree more with
this post, especially 'least astonishment'.
On Mon, Sep 16, 2019 at 09:42:56AM -0400, Clem Cole wrote:
> What irks me is the blatant force-feeding of any system to the users, be it
> ITS, UNIX or Windows into another. It's ok to offer an alternative
> interface, but when the system has a mechanism, your tools need to be *socially
> compliant* with it, not try to make 'those users become like me.'
> Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
> two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to
> rule).
>
> BTW: If it makes you feel better, I've been fighting this attitude at a
> number of places, particularly Intel, for years. For instance, our dev
> tools folks wrote their own Installer 'because it was easier for them and
> they could use it everywhere'). That's a no-no. If you have Windows
> product, you must use Microsoft's installer, if you have a Mac, you use
> what Apple gives you, if you have VMS, you used the (wretched) setld, or in
> this case, for Linux its rpm/yum et al.; etc. But they had their own
> 'installer group' and it was easier for >>them<< than for the users.
>
> I think the rule of 'least astonishment' is what needs to be the high order
> bit when building tools for people. Again, offering emacs (or any other
> ITS tool) is fine, but when the new tool is installed on Windows/UNIX/Mac
> et.. it needs to behave itself with the rest of the system, particularly if
> there is already a mechanism in place to do a support function.
>
> Simply, I would not mind info(gnu) and texinfo(gnu) if there was a way to
> created man pages (or Windows / Mac help). But having a man page that
> basically says, see figure one
> <https://www.dourish.com/goodies/see-figure-1.html> is not cool.
>
> my 2 cents from a grumpy old guy....
> Clem
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 13:42 ` Clem Cole
2019-09-16 14:54 ` Larry McVoy
@ 2019-09-16 16:09 ` Paul Winalski
2019-09-16 22:05 ` Dave Horsfall
2 siblings, 0 replies; 103+ messages in thread
From: Paul Winalski @ 2019-09-16 16:09 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
On 9/16/19, Clem Cole <clemc@ccc.com> wrote:
> On Mon, Sep 16, 2019 at 8:26 AM Lars Brinkhoff <lars@nocrew.org> wrote:
>
> What irks me is the blatant force-feeding of any system to the users, be it
> ITS, UNIX or Windows into another. It's ok to offer an alternative
> interface, but when the system has a mechanism, your tools need to be
> *socially
> compliant* with it, not try to make 'those users become like me.'
> Frankly, that is a pretty arrogant behavior. Yes, I know the argument is
> two fold. GNU is not UNIX and we wrote it (he who has the gold, gets to
> rule).
Amen to that! As the old saying goes, "when in Rome, do as the Romans
do". On UNIX, tools are expected to send output to stdout. On
Windows, users expect text selection and ^C/^V copy-and-paste to work.
On VMS, you use the CLI interface to parse the command line. And so
on. The principle of least astonishment should always be foremost in
user interaction design.
> BTW: If it makes you feel better, I've been fighting this attitude at a
> number of places, particularly Intel, for years. For instance, our dev
> tools folks wrote their own Installer 'because it was easier for them and
> they could use it everywhere'). That's a no-no. If you have Windows
> product, you must use Microsoft's installer, if you have a Mac, you use
> what Apple gives you, if you have VMS, you used the (wretched) setld, or in
> this case, for Linux its rpm/yum et al.; etc. But they had their own
> 'installer group' and it was easier for >>them<< than for the users.
I used to work in that organization. The installer situation is one
of the worst cases of not-invented-here syndrome that I've ever seen.
Or maybe it was just empire building by some ambitious manager. The
"it's easier for us and we can use it everywhere" argument is pure BS.
Any savings that they got from having the a common code base for the
installer was wiped out by all the extra development effort needed to
track the release-to-release changes that the various platforms made
to their software deployment setup. Their installer was always a step
or two behind the curve, late in supporting new platform features, and
full of subtle bugs and mis-implemented edge conditions. It wasn't
really "easier for them" in the long run after all. It was a
maintenance nightmare.
-Paul W.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 13:42 ` Clem Cole
2019-09-16 14:54 ` Larry McVoy
2019-09-16 16:09 ` Paul Winalski
@ 2019-09-16 22:05 ` Dave Horsfall
2019-09-16 22:33 ` reed
` (2 more replies)
2 siblings, 3 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-16 22:05 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 600 bytes --]
On Mon, 16 Sep 2019, Clem Cole wrote:
> > However, please note that more(1) also was inspired by, almost
> > copied from, ITS. Certainly the prompt --More-- is.
>
> Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood,
> wrote it. He was a MIT undergrad. And Eric happily said it was modeled
> from ITS. And before, Eric wrote it, UNIX lacked anything like it.
> Which to me is fine, taking an idea from another system to add a new
> feature that is lacking.
Am I the only one who remembers the old "pg" program? It seems to have
disappeared.
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 22:05 ` Dave Horsfall
@ 2019-09-16 22:33 ` reed
2019-09-17 0:11 ` Dave Horsfall
2019-09-17 0:02 ` Nemo Nusquam
2019-09-17 0:46 ` Clem Cole
2 siblings, 1 reply; 103+ messages in thread
From: reed @ 2019-09-16 22:33 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
> Am I the only one who remembers the old "pg" program? It seems to have
> disappeared.
I see two different pg. One in the 32V sources and the other first
Usenix delaware collection. (Both in TUHS archives)
Another pager "cr3" is in 1BSD collection (which was replaced by
Halbert's more in 3BSD).
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 22:33 ` reed
@ 2019-09-17 0:11 ` Dave Horsfall
0 siblings, 0 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-17 0:11 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Mon, 16 Sep 2019, reed@reedmedia.net wrote:
>> Am I the only one who remembers the old "pg" program? It seems to have
>> disappeared.
>
> I see two different pg. One in the 32V sources and the other first
> Usenix delaware collection. (Both in TUHS archives)
We never ran 32V; our Vaxen - called "vaxa" and "vaxb" - ran VMS... I was
only in charge of the Unix PDP-11/40s sprinkled around the place (and the
odd /34 and /23).
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 22:05 ` Dave Horsfall
2019-09-16 22:33 ` reed
@ 2019-09-17 0:02 ` Nemo Nusquam
2019-09-17 0:21 ` Arthur Krewat
2019-09-17 11:12 ` Thomas Paulsen
2019-09-17 0:46 ` Clem Cole
2 siblings, 2 replies; 103+ messages in thread
From: Nemo Nusquam @ 2019-09-17 0:02 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
On 09/16/19 18:05, Dave Horsfall wrote:
> Am I the only one who remembers the old "pg" program? It seems to have
> disappeared.
Still ships with Solaris (in /usr/bin).
N.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 22:05 ` Dave Horsfall
2019-09-16 22:33 ` reed
2019-09-17 0:02 ` Nemo Nusquam
@ 2019-09-17 0:46 ` Clem Cole
2 siblings, 0 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-17 0:46 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
The USG pg program was created after UCB released more. Btw this was
before vi or csh was distributed. But too many BTL folks had seen BSD
during there OYOC year and either demanded it or had brought what was in
effect 2BSD back with them.
On Mon, Sep 16, 2019 at 6:06 PM Dave Horsfall <dave@horsfall.org> wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
>
> > > However, please note that more(1) also was inspired by, almost
> > > copied from, ITS. Certainly the prompt --More-- is.
> >
> > Absolutely. A friend of mine/fellow UCB grad student, Eric Shienbrood,
> > wrote it. He was a MIT undergrad. And Eric happily said it was modeled
> > from ITS. And before, Eric wrote it, UNIX lacked anything like it.
> > Which to me is fine, taking an idea from another system to add a new
> > feature that is lacking.
>
> Am I the only one who remembers the old "pg" program? It seems to have
> disappeared.
>
> -- Dave
--
Sent from a handheld expect more typos than usual
[-- Attachment #2: Type: text/html, Size: 1453 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:10 ` Clem Cole
2019-09-16 12:26 ` Lars Brinkhoff
@ 2019-09-16 13:13 ` Chet Ramey
2019-09-16 14:51 ` Larry McVoy
` (2 subsequent siblings)
4 siblings, 0 replies; 103+ messages in thread
From: Chet Ramey @ 2019-09-16 13:13 UTC (permalink / raw)
To: Clem Cole, Aharon Robbins; +Cc: The Eunuchs Hysterical Society
On 9/16/19 8:10 AM, Clem Cole wrote:
> I use the standalone Info reader (named info) if I want to look at the
> Info output.
>
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
>
> If it would have used more(1) [or even less(1)] then I would not be as annoyed.
It seems to me that the strength of info (the file format and program) is
the navigation of a menu-driven hierarchical document containing what are
essentially selectable links between sections. Something like more or less
is poorly suited to take advantage of those features.
You need a way to position the cursor with more flexibility than more gives
you.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:10 ` Clem Cole
2019-09-16 12:26 ` Lars Brinkhoff
2019-09-16 13:13 ` Chet Ramey
@ 2019-09-16 14:51 ` Larry McVoy
2019-09-16 14:57 ` Clem Cole
2019-09-17 7:53 ` arnold
2019-09-16 21:42 ` Dave Horsfall
2019-10-05 19:44 ` Michael Parson
4 siblings, 2 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 14:51 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
>
> > I use the standalone Info reader (named info) if I want to look at the
> > Info output.
> >
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
>
> If it would have used more(1) [or even less(1)] then I would not be as
> annoyed.
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> need to replace them with ITS-like programs.
I hate texinfo and friends. I get why it is better than man, but man was
good enough, more than good enough, and the GNU project took everything
it could find and destroyed the man pages.
If you have something like perl that needs a zillion sub pages, info
makes sense. For just a man page, info is horrible.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 14:51 ` Larry McVoy
@ 2019-09-16 14:57 ` Clem Cole
2019-09-16 15:14 ` Richard Salz
2019-09-16 22:35 ` Dave Horsfall
2019-09-17 7:53 ` arnold
1 sibling, 2 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-16 14:57 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Mon, Sep 16, 2019 at 10:51 AM Larry McVoy <lm@mcvoy.com> wrote:
> I hate texinfo and friends. I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
Amen, bro. As I said, it was not 'social compliant' which was really a
not very nice thing to do. It's arrogant to say in effect "your way is
wrong, I'm going to try to kill it off."
>
> If you have something like perl that needs a zillion sub pages, info
> makes sense. For just a man page, info is horrible.
I'm not even sure, I like that, to be honest. I'm 'old school' enough to
rather use a book from ORA or the like.
[-- Attachment #2: Type: text/html, Size: 1693 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 14:57 ` Clem Cole
@ 2019-09-16 15:14 ` Richard Salz
2019-09-16 15:48 ` Ronald Natalie
` (3 more replies)
2019-09-16 22:35 ` Dave Horsfall
1 sibling, 4 replies; 103+ messages in thread
From: Richard Salz @ 2019-09-16 15:14 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
Is it any surprise that the early GNU effort was really trying to recreate
ITS? Can you really blame them? I'm grateful that they made `info` be a
standalone program. Putting the concept of "cursor position" into the
existing pagers (more/less/etc) and doing jump/xref/back would be more than
a stretch, IMO.
[-- Attachment #2: Type: text/html, Size: 370 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 15:14 ` Richard Salz
@ 2019-09-16 15:48 ` Ronald Natalie
2019-09-16 16:10 ` Larry McVoy
` (2 subsequent siblings)
3 siblings, 0 replies; 103+ messages in thread
From: Ronald Natalie @ 2019-09-16 15:48 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
> On Sep 16, 2019, at 11:14 AM, Richard Salz <rich.salz@gmail.com> wrote:
>
> Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
>
Having been an early UNIX Emacs adoptee (I never really learned VI, if there was no emacs, I just used ed. A tendency that my employees always found amusing), I could never tolerate INFO in any of its forms (either ITS or on UNIX).
It was far too cumbersome for the features it claimed to add to the mix.
As for formatters, my biggest gripe with many of them is that I should not be able to tell what the formatter is by looking at the output. This is where Tex fails. It’s ugly style always seems to telegraph through. The only thing that is worse is those odd little bumps on the top of pic-framed tbl output.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 15:14 ` Richard Salz
2019-09-16 15:48 ` Ronald Natalie
@ 2019-09-16 16:10 ` Larry McVoy
2019-09-16 16:16 ` Jon Steinhart
2019-09-17 11:20 ` Thomas Paulsen
2019-09-16 19:13 ` Steffen Nurpmeso
2019-09-16 19:31 ` Bakul Shah
3 siblings, 2 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 16:10 UTC (permalink / raw)
To: Richard Salz; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> Is it any surprise that the early GNU effort was really trying to recreate
> ITS? Can you really blame them? I'm grateful that they made `info` be a
> standalone program. Putting the concept of "cursor position" into the
> existing pagers (more/less/etc) and doing jump/xref/back would be more than
> a stretch, IMO.
It's what Clem said. You should acclimate yourself to your environment.
Pushing info into man environment is a lot like being an immigrant and
wanting to bring your laws into your new homeland. That isn't a thing
and shouldn't be a thing. Doesn't matter that people think ITS is better,
they are in Unix. If you think ITS is better, go live there.
When in Rome....
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:10 ` Larry McVoy
@ 2019-09-16 16:16 ` Jon Steinhart
2019-09-16 16:26 ` Larry McVoy
2019-09-17 11:20 ` Thomas Paulsen
1 sibling, 1 reply; 103+ messages in thread
From: Jon Steinhart @ 2019-09-16 16:16 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Larry McVoy writes:
> On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > Is it any surprise that the early GNU effort was really trying to recreate
> > ITS? Can you really blame them? I'm grateful that they made `info` be a
> > standalone program. Putting the concept of "cursor position" into the
> > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > a stretch, IMO.
>
> It's what Clem said. You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland. That isn't a thing
> and shouldn't be a thing. Doesn't matter that people think ITS is better,
> they are in Unix. If you think ITS is better, go live there.
>
> When in Rome....
Well, in the shameless department, I can quote from my book:
Mucking up the ecosystem into which you release code does not
add value. Many developers behave as if they’re stereotypical
Americans vacationing in another country, or for that matter my
father-in-law visiting — the “I just came to your place, so do
things my way” attitude.
For example, UNIX systems have a command that displays manual pages
for programs. You can type man foo and it’ll show you the page
for the foo command. There’s also a convention that really complex
commands, such as yacc , have both a manual page and a longer, more
in-depth document that describes the program in more detail. When
the GNU project (which I’ll discuss shortly) added commands to
UNIX, it used its own texinfo system for manuals, which wasn’t
compatible with the man system. The result was that users would have
to try both the man and info commands to find documentation. Even
if, as some believe, the GNU approach was superior, any possible
benefits were outweighed by the UNIX community’s huge loss of
productivity that resulted from the fragmented ecosystem.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:16 ` Jon Steinhart
@ 2019-09-16 16:26 ` Larry McVoy
2019-09-16 16:31 ` Richard Salz
0 siblings, 1 reply; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 16:26 UTC (permalink / raw)
To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society
+1
On Mon, Sep 16, 2019 at 09:16:03AM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> > On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > > Is it any surprise that the early GNU effort was really trying to recreate
> > > ITS? Can you really blame them? I'm grateful that they made `info` be a
> > > standalone program. Putting the concept of "cursor position" into the
> > > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > > a stretch, IMO.
> >
> > It's what Clem said. You should acclimate yourself to your environment.
> > Pushing info into man environment is a lot like being an immigrant and
> > wanting to bring your laws into your new homeland. That isn't a thing
> > and shouldn't be a thing. Doesn't matter that people think ITS is better,
> > they are in Unix. If you think ITS is better, go live there.
> >
> > When in Rome....
>
> Well, in the shameless department, I can quote from my book:
>
> Mucking up the ecosystem into which you release code does not
> add value. Many developers behave as if they???re stereotypical
> Americans vacationing in another country, or for that matter my
> father-in-law visiting ??? the ???I just came to your place, so do
> things my way??? attitude.
>
> For example, UNIX systems have a command that displays manual pages
> for programs. You can type man foo and it???ll show you the page
> for the foo command. There???s also a convention that really complex
> commands, such as yacc , have both a manual page and a longer, more
> in-depth document that describes the program in more detail. When
> the GNU project (which I???ll discuss shortly) added commands to
> UNIX, it used its own texinfo system for manuals, which wasn???t
> compatible with the man system. The result was that users would have
> to try both the man and info commands to find documentation. Even
> if, as some believe, the GNU approach was superior, any possible
> benefits were outweighed by the UNIX community???s huge loss of
> productivity that resulted from the fragmented ecosystem.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:26 ` Larry McVoy
@ 2019-09-16 16:31 ` Richard Salz
2019-09-16 16:45 ` Larry McVoy
2019-09-16 17:00 ` Clem Cole
0 siblings, 2 replies; 103+ messages in thread
From: Richard Salz @ 2019-09-16 16:31 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
I don't think it's totally GNU's fault that it became Linux. They weren't
trying to be tourists in Rome, they were trying to create a new city of
their own.
[-- Attachment #2: Type: text/html, Size: 229 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:31 ` Richard Salz
@ 2019-09-16 16:45 ` Larry McVoy
2019-09-16 17:19 ` KatolaZ
2019-09-16 17:24 ` Clem Cole
2019-09-16 17:00 ` Clem Cole
1 sibling, 2 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 16:45 UTC (permalink / raw)
To: Richard Salz; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 12:31:13PM -0400, Richard Salz wrote:
> I don't think it's totally GNU's fault that it became Linux. They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.
Yeah, except they didn't create their own city, they pooped all over a
different one. There is no defense for what they did. If they did the
right thing they would have created a markup language that could have
produced info files and man files.
It's not that hard, I wrote something called webroff that took -ms
format input and produced a website complete with the navigation tree,
it defaulted to showing you a page (each .NH) at time but it also had
a site map where you could see the entire document as a single page,
or each major section (.NH 1) as a page.
For more than a decade this was BitMover's home page. I can't tell
you how many sales calls I've been on and I've seen the entire web
site printed out on the manager's desk.
The reality is there was absolutely no need for a new format for
info files, they could have parsed man input and produced info
files and that's what they should have done.
Those who defend the choice of info over man just aren't real Unix
people. And that's fine, Unix isn't the only choice, they can go
run some other OS and be happy. But it's just rude to thrust info
into a Unix system. And lame because they could have parsed man
pages into info docs and then they are adopting the Unix way of
doing things and actually adding value.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:45 ` Larry McVoy
@ 2019-09-16 17:19 ` KatolaZ
2019-09-16 17:24 ` Larry McVoy
` (2 more replies)
2019-09-16 17:24 ` Clem Cole
1 sibling, 3 replies; 103+ messages in thread
From: KatolaZ @ 2019-09-16 17:19 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
[cut]
>
> Those who defend the choice of info over man just aren't real Unix
> people. And that's fine, Unix isn't the only choice, they can go
> run some other OS and be happy. But it's just rude to thrust info
> into a Unix system. And lame because they could have parsed man
> pages into info docs and then they are adopting the Unix way of
> doing things and actually adding value.
Sorry, but I totally don't see the point here. The problem is not the
technology, but the adopters. I personally don't like info at all, and
still swear whenever a software comes without a proper manpage, but
info has not been shovelled down your throat (or anybody else's, for
that matter). The adopters have decided that info was fine for their
use case. They could have written manpages and send patches over, and
in many cases they didn't.
There is plenty of software coming from the GNU project that has
comprehensive and clear manpages (just to cite a single example,
bash(1) comes with manpages, and no info doc). At the same time, there
is tons of "Unix" software around that comes without any documentation
*at all*, or with scant text files covering the bare basics.
Unfortunately this trend is only getting worse, and we have far too
many notaable examples here, not all of them coming from the GNU
project, or from the "ITS tradition", whatever it means for you.
I agree that whoever does not produce a readily usable documentaion
for their software has not really understood much of the Unix
philosophy. But that's not at all a matter of formats, rather of
culture.
Then, if you just want to vomit on info, or you prefer to use info as
another excuse to vomit on the GNU project, well go ahead. But the
actual issue is elsewhere (the lack of respect for the users, and the
tendency to hide stuff under the carpet), and has not been introduced
by the GNU project, at all.
My2Cents
Enzo Nicosia
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 17:19 ` KatolaZ
@ 2019-09-16 17:24 ` Larry McVoy
2019-09-16 17:32 ` Jon Steinhart
2019-09-16 17:35 ` Clem Cole
2019-09-16 17:37 ` Jon Steinhart
2019-09-16 18:04 ` Chet Ramey
2 siblings, 2 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 17:24 UTC (permalink / raw)
To: KatolaZ; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
>
> [cut]
>
> >
> > Those who defend the choice of info over man just aren't real Unix
> > people. And that's fine, Unix isn't the only choice, they can go
> > run some other OS and be happy. But it's just rude to thrust info
> > into a Unix system. And lame because they could have parsed man
> > pages into info docs and then they are adopting the Unix way of
> > doing things and actually adding value.
>
> Sorry, but I totally don't see the point here.
Jon put it well, the point is people expect to be able to say
man foo
and have that work. Until GNU came along, that's the way it was.
GNU pushed a different system into the mix.
The secondary point is they could have *added* to Unix by making a
man2info command, I know they could have because I've done something
similar, parsing man or -ms pages is trivial.
GNU choose not to do that and I can't begin to express how wrong
that was. GNU is not Unix for sure.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 17:24 ` Larry McVoy
@ 2019-09-16 17:32 ` Jon Steinhart
2019-09-16 17:35 ` Clem Cole
1 sibling, 0 replies; 103+ messages in thread
From: Jon Steinhart @ 2019-09-16 17:32 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Larry McVoy writes:
> On Mon, Sep 16, 2019 at 07:19:05PM +0200, KatolaZ wrote:
> > On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
> >
> > [cut]
> >
> > >
> > > Those who defend the choice of info over man just aren't real Unix
> > > people. And that's fine, Unix isn't the only choice, they can go
> > > run some other OS and be happy. But it's just rude to thrust info
> > > into a Unix system. And lame because they could have parsed man
> > > pages into info docs and then they are adopting the Unix way of
> > > doing things and actually adding value.
> >
> > Sorry, but I totally don't see the point here.
>
> Jon put it well, the point is people expect to be able to say
>
> man foo
>
> and have that work. Until GNU came along, that's the way it was.
> GNU pushed a different system into the mix.
>
> The secondary point is they could have *added* to Unix by making a
> man2info command, I know they could have because I've done something
> similar, parsing man or -ms pages is trivial.
>
> GNU choose not to do that and I can't begin to express how wrong
> that was. GNU is not Unix for sure.
So I'm not really trying to be all that shameless, it's just that I've already
written down my opinions on this sort of stuff and don't need to retype it all.
From a section entitled "The Value Proposition":
There's an overarching question that you should keep in mind when
working on a project: "Am I adding value?" I'm not talking about
the intrinsic value of accomplishing some task here; I'm talking
about increasing productivity.
If you're programming for a living, you need to meet whatever goals
your employer has set. But, of course, there's more than one way
to meet those goals. You could just do what you need to do to get
by. Or, you could put a little thought into things that might not
have occurred to management. For example, you might realize that
your code would be useful in another project and structure it so
it's easily reusable. Or, you might sense that you were tasked to
implement a special case of a more general problem and solve that
general problem instead, paving the way for future enhancements.
Of course, you should talk about this with management so that
they're not surprised.
You can add value to yourself by making sure that you're proficient
in a variety of technologies. Side projects are a common way to
get experience; it's equivalent to doing homework but more fun.
One classic way in which people attempt to add value is by
creating tools. This is trickier than it seems because sometimes
adding value for yourself reduces value for others. People often
create new tools because some feature that they think they need
is missing from existing ones. A good example is the make utility
(invented by Stuart Feldman at Bell Labs in 1976), which is used to
build large software packages. As time went on, new features were
needed. Some of these were added to make, but in many other cases,
people created well-intentioned but incompatible new utilities
that performed similar functions. (For example, I consulted for
a company once that wrote their own solely because they didn't
bother to completely read the make documentation and were unaware
that it would do exactly what they needed.) Now there's make,
cmake, dmake, imake, pick-a-letter-make, and other programs that
all do similar things in incompatible ways. The result is that
practitioners like you need to learn multiple tools in each category.
It makes everyone's life harder, not easier. It doesn't add
value—it detracts. Figure 15-1 sums up the situation nicely.
[ Figure 15-1 is the xkcd how standards proliferate cartoon ]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 17:24 ` Larry McVoy
2019-09-16 17:32 ` Jon Steinhart
@ 2019-09-16 17:35 ` Clem Cole
1 sibling, 0 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-16 17:35 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Mon, Sep 16, 2019 at 1:24 PM Larry McVoy <lm@mcvoy.com> wrote:
> The secondary point is they could have *added* to Unix by making a
> man2info command
>
Exactly!!!! That's what Eric did when he wrote more(ucb) - he *added to
Unix*. The funny part was that USG thought more(ucb) was a good idea and
then wrote their own, pg(att); which was just as arrogant as the info
behavior from the Gnu folks!!! Later, Less(internet) replaced more, but
only as a superset, building on the foundation and eventually USB chose to
ship more also as so many people wanted it.
As I said yesterday, standing on the shoulders, not on their toes.
[-- Attachment #2: Type: text/html, Size: 1437 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 17:19 ` KatolaZ
2019-09-16 17:24 ` Larry McVoy
@ 2019-09-16 17:37 ` Jon Steinhart
2019-09-16 18:04 ` Chet Ramey
2 siblings, 0 replies; 103+ messages in thread
From: Jon Steinhart @ 2019-09-16 17:37 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
KatolaZ writes:
> Sorry, but I totally don't see the point here. The problem is not the
> technology, but the adopters. I personally don't like info at all, and
> still swear whenever a software comes without a proper manpage, but
> info has not been shovelled down your throat (or anybody else's, for
> that matter). The adopters have decided that info was fine for their
> use case. They could have written manpages and send patches over, and
> in many cases they didn't.
>
> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc). At the same time, there
> is tons of "Unix" software around that comes without any documentation
> *at all*, or with scant text files covering the bare basics.
>
> Unfortunately this trend is only getting worse, and we have far too
> many notaable examples here, not all of them coming from the GNU
> project, or from the "ITS tradition", whatever it means for you.
>
> I agree that whoever does not produce a readily usable documentaion
> for their software has not really understood much of the Unix
> philosophy. But that's not at all a matter of formats, rather of
> culture.
>
> Then, if you just want to vomit on info, or you prefer to use info as
> another excuse to vomit on the GNU project, well go ahead. But the
> actual issue is elsewhere (the lack of respect for the users, and the
> tendency to hide stuff under the carpet), and has not been introduced
> by the GNU project, at all.
>
> My2Cents
>
> Enzo Nicosia
It seems to me that you're missing the point here. It's not a question of
whether or not GNU programs have good documentation. It's the fact that
GNU made it hard to find documentation because they took one pile and split
it into two with no guide to what was in each pile. It's not that their
documentation was good or bad, it's that they made it hard to find any
documentation.
Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this
one (from Alice's Restaurant): "And we decided that one big pile is better
than two little piles, and rather than bring that one up we decided to throw
ours down."
Jon
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 17:19 ` KatolaZ
2019-09-16 17:24 ` Larry McVoy
2019-09-16 17:37 ` Jon Steinhart
@ 2019-09-16 18:04 ` Chet Ramey
2019-09-16 18:19 ` KatolaZ
2019-09-16 23:24 ` Dave Horsfall
2 siblings, 2 replies; 103+ messages in thread
From: Chet Ramey @ 2019-09-16 18:04 UTC (permalink / raw)
To: KatolaZ, Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --]
On 9/16/19 1:19 PM, KatolaZ wrote:
> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc).
Bash comes with both a large man page and an extensive info doc.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 18:04 ` Chet Ramey
@ 2019-09-16 18:19 ` KatolaZ
2019-09-16 23:24 ` Dave Horsfall
1 sibling, 0 replies; 103+ messages in thread
From: KatolaZ @ 2019-09-16 18:19 UTC (permalink / raw)
To: Chet Ramey; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
On Mon, Sep 16, 2019 at 02:04:00PM -0400, Chet Ramey wrote:
> On 9/16/19 1:19 PM, KatolaZ wrote:
>
> > There is plenty of software coming from the GNU project that has
> > comprehensive and clear manpages (just to cite a single example,
> > bash(1) comes with manpages, and no info doc).
>
> Bash comes with both a large man page and an extensive info doc.
>
Yep, sorry! I meant "and not only an info doc". And they are both of
very good quality, IMHO.
HND
Enzo Nicosia
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 18:04 ` Chet Ramey
2019-09-16 18:19 ` KatolaZ
@ 2019-09-16 23:24 ` Dave Horsfall
1 sibling, 0 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-16 23:24 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Mon, 16 Sep 2019, Chet Ramey wrote:
> Bash comes with both a large man page and an extensive info doc.
On my (obsolete) FreeBSD box:
aneurin% man bash | wc -l
5947
Now there's a manpage that should have been split up...
On the same box:
aneurin% man zsh | wc -l
346
That's because it's got sub-pages, each describing a particular feature
(I've been using ZSH for years).
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:45 ` Larry McVoy
2019-09-16 17:19 ` KatolaZ
@ 2019-09-16 17:24 ` Clem Cole
1 sibling, 0 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-16 17:24 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]
On Mon, Sep 16, 2019 at 12:45 PM Larry McVoy <lm@mcvoy.com> wrote:
> Yeah, except they didn't create their own city, they pooped all over a
> different one.
peed *vs.* pooped - one is marking territory while the other is destroying
it.
It is interesting that both analogs work here, however.
There is no defense for what they did. If they did the
> right thing they would have created a markup language that could have
> produced info files and man files.
>
+1 and that's why it is even more difficult to understand. Being polite
and 'fitting in' would really not been any harder than being like Jon's
father-in-law.
> ....
> Those who defend the choice of info over man just aren't real Unix people.
I'd maybe say it as they don't want to be real Unix people and fit it with
the rest.
> And that's fine, Unix isn't the only choice, they can go
> run some other OS and be happy.
Frankly, trying to turn a Lisp Machine into a "Unix box" would have been as
much of sin, in my eyes. Hey, I'm thrilled to see rms and his friends can
build and purchase as many LMI box as he would like (But I do observe, the
'technically superior system,' in the end, wasn't very economical). I
really don't mind bringing things over (like more, or job control, or
command/filename completion that all came from other systems). That is
really adding value to the new system (UNIX in this case).
But it's just rude to thrust info
> into a Unix system. And lame because they could have parsed man
> pages into info docs and then they are adopting the Unix way of
> doing things and actually adding value.
touché
As Larry and Jon have said better than I, it was the seemly effect of trying
to replace man with info that I just don't understand. As Larry has
said if they had made a way go from texinfo to man, even if it had been a
little rough on the edges, I might have grumbled, but I would have tried to
use it. The truth is today, like many other Unix hacker I know, if I am
offered a new tool but using it means that I am being led down a path to use
info/texinfo, I rethink if I want to use that new tool or not. It's a big
turn off for me to want to learn to use such a tool since I know the
authors have made no attempt to integrate it into a traditional UNIX
workflow if they have not built proper man pages, much less written
traditional docs.
[-- Attachment #2: Type: text/html, Size: 5465 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:31 ` Richard Salz
2019-09-16 16:45 ` Larry McVoy
@ 2019-09-16 17:00 ` Clem Cole
1 sibling, 0 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-16 17:00 UTC (permalink / raw)
To: Richard Salz; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
I note that it wasn't "GNI" it was GNU or he would have started with LISP.
The fact is rms started by wanting to hack/rewrite Gosling EMACS as it had
been released and some of the other C versions were at the same time a
little less open to him as a starting point. Since it was not in LISP, he
needed to write a C Compiler (which I still think is the #1 positive thing
from the Gnu project and in the end, I believe that it was others that
really made the compiler the success, not rms other than he tirelessly
championed it). The reality is that the Gnu team quick set out to rewrite
the UNIX tools and used Trix (a UNIX clone) as the original OS. Hurd did
not come until later and in the Linux became the kernel it lived upon (as
Jon says, it's Internet/Linux not Gnu/Linux).
Sorry, IMO, rms tried to 'pee on Unix to make it smell like ITS' - not
surprising as you say. But pretty darned arrogant none-the less. The
results makes using many of the tools "astonishing" to everyone else.
+1 to Jon's comments.
"Even if, as some believe, the GNU approach was superior, any possible benefits
were outweighed by the UNIX community’s huge loss of productivity that
resulted from the fragmented ecosystem."
Amen brother Jon, and this week's free will offering will be sponsoring ....
On Mon, Sep 16, 2019 at 12:31 PM Richard Salz <rich.salz@gmail.com> wrote:
> I don't think it's totally GNU's fault that it became Linux. They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.
>
[-- Attachment #2: Type: text/html, Size: 3299 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:10 ` Larry McVoy
2019-09-16 16:16 ` Jon Steinhart
@ 2019-09-17 11:20 ` Thomas Paulsen
1 sibling, 0 replies; 103+ messages in thread
From: Thomas Paulsen @ 2019-09-17 11:20 UTC (permalink / raw)
To: Larry McVoy; +Cc: tuhs
Larry McVoy <lm@mcvoy.com> wrote:
>
> It's what Clem said. You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland. That isn't a thing
> and shouldn't be a thing. Doesn't matter that people think ITS is better,
> they are in Unix. If you think ITS is better, go live there.
> When in Rome....
>
info failed (as well as texinfo). Hardly anybody using it, beside notorious emacs maniacs like me. Rome doesn't like it.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 15:14 ` Richard Salz
2019-09-16 15:48 ` Ronald Natalie
2019-09-16 16:10 ` Larry McVoy
@ 2019-09-16 19:13 ` Steffen Nurpmeso
2019-09-16 19:31 ` Bakul Shah
3 siblings, 0 replies; 103+ messages in thread
From: Steffen Nurpmeso @ 2019-09-16 19:13 UTC (permalink / raw)
To: Richard Salz; +Cc: The Eunuchs Hysterical Society
Richard Salz wrote in <CAFH29tpP6joyHDAQTKj41bwAscqa0HO8g7EKwxXv3Vbscqc5\
8A@mail.gmail.com>:
|Is it any surprise that the early GNU effort was really trying to recreate \
|ITS? Can you really blame them? I'm grateful that they made `info` \
|be a standalone program. Putting the concept of "cursor
|position" into the existing pagers (more/less/etc) and doing jump/xref/b\
|ack would be more than a stretch, IMO.
So that is actually not true, really.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 15:14 ` Richard Salz
` (2 preceding siblings ...)
2019-09-16 19:13 ` Steffen Nurpmeso
@ 2019-09-16 19:31 ` Bakul Shah
3 siblings, 0 replies; 103+ messages in thread
From: Bakul Shah @ 2019-09-16 19:31 UTC (permalink / raw)
To: Richard Salz; +Cc: The Eunuchs Hysterical Society
The way Rob solved the problem in acme(1) is much nicer.
Right click on |open(2)| and its man page opens up in a
new window. You can do the same on any manpage mentioned
in the SEE ALSO section or anywhere else and you can see
their man page without any side-effect on the original
window. He didn't throw out any old documentation but
added a a new tool to make navigation easier (and it is
more general in that you can define right click actions).
There was already cursor positioning available in vi. It
would not have been a real stretch to hack in acme like
support in less or vi (clumsier without a mouse but still).
In fact tag support in vi already did something like it
with ^] and ^^ for jump/back.
> On Sep 16, 2019, at 8:14 AM, Richard Salz <rich.salz@gmail.com> wrote:
>
> Is it any surprise that the early GNU effort was really trying to recreate ITS? Can you really blame them? I'm grateful that they made `info` be a standalone program. Putting the concept of "cursor position" into the existing pagers (more/less/etc) and doing jump/xref/back would be more than a stretch, IMO.
>
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 14:57 ` Clem Cole
2019-09-16 15:14 ` Richard Salz
@ 2019-09-16 22:35 ` Dave Horsfall
1 sibling, 0 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-16 22:35 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
On Mon, 16 Sep 2019, Clem Cole wrote:
> > If you have something like perl that needs a zillion sub pages,
> > info makes sense. For just a man page, info is horrible.
>
> I'm not even sure, I like that, to be honest. I'm 'old school' enough to
> rather use a book from ORA or the like.
Or use www.perltutorial.org which is a good resource; I often get stuck
on the finer points of Perl, such as the OO stuff.
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 14:51 ` Larry McVoy
2019-09-16 14:57 ` Clem Cole
@ 2019-09-17 7:53 ` arnold
2019-09-17 14:21 ` Clem Cole
2019-09-17 15:58 ` Christopher Browne
1 sibling, 2 replies; 103+ messages in thread
From: arnold @ 2019-09-17 7:53 UTC (permalink / raw)
To: lm, clemc; +Cc: tuhs
It is like clockwork.
Whenever I say something about Texinfo *as a markup language* for use
in *writing books*, the discussion inevitably degenerates into a hate
rant against Info and RMS's (failed) attempt to replace man pages.
Totally missing the point too.
This is a trend on TUHS. The same discussions, the same rants, often
the same misinformation, over and over and over again.
I start to wonder if I should continue to subscribe.
Arnold
Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> >
> > > I use the standalone Info reader (named info) if I want to look at the
> > > Info output.
> > >
> > Fair enough, but be careful, while I admit I have not looked in a while,
> > info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> > Every time I have tried to deal with it, I have unprogram my fingers and
> > reset them to emacs.
> >
> > If it would have used more(1) [or even less(1)] then I would not be as
> > annoyed.
> > Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> > need to replace them with ITS-like programs.
>
> I hate texinfo and friends. I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
> If you have something like perl that needs a zillion sub pages, info
> makes sense. For just a man page, info is horrible.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 7:53 ` arnold
@ 2019-09-17 14:21 ` Clem Cole
2019-09-17 15:03 ` arnold
2019-09-17 15:58 ` Christopher Browne
1 sibling, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-17 14:21 UTC (permalink / raw)
To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
Fair enough. Mei culpa from one of those that was vocal. That said, maybe
a trick is to stay away from texinfo/info and the man page discussion on
this list since its a hot button that causes much trama for some with a
more traditional UNIX view.
Please don't leave, your voice is important and I generally agree with you
and always like to hear you out. But even if I do not agree, I still want
to listen. You have come to your conclusions in a different manner than
some of us, and where each of us puts the MSB tends to color our views.
Diversity of opinion is a good thing.
Respectfully,
Clem
ᐧ
On Tue, Sep 17, 2019 at 3:53 AM <arnold@skeeve.com> wrote:
> It is like clockwork.
>
> Whenever I say something about Texinfo *as a markup language* for use
> in *writing books*, the discussion inevitably degenerates into a hate
> rant against Info and RMS's (failed) attempt to replace man pages.
> Totally missing the point too.
>
> This is a trend on TUHS. The same discussions, the same rants, often
> the same misinformation, over and over and over again.
>
> I start to wonder if I should continue to subscribe.
>
> Arnold
>
> Larry McVoy <lm@mcvoy.com> wrote:
>
> > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> > >
> > > > I use the standalone Info reader (named info) if I want to look at
> the
> > > > Info output.
> > > >
> > > Fair enough, but be careful, while I admit I have not looked in a
> while,
> > > info(gnu) relies on emacs keybindings and a number of very emacs'ish
> things.
> > > Every time I have tried to deal with it, I have unprogram my fingers
> and
> > > reset them to emacs.
> > >
> > > If it would have used more(1) [or even less(1)] then I would not be as
> > > annoyed.
> > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> the
> > > need to replace them with ITS-like programs.
> >
> > I hate texinfo and friends. I get why it is better than man, but man was
> > good enough, more than good enough, and the GNU project took everything
> > it could find and destroyed the man pages.
> >
> > If you have something like perl that needs a zillion sub pages, info
> > makes sense. For just a man page, info is horrible.
>
[-- Attachment #2: Type: text/html, Size: 3490 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 14:21 ` Clem Cole
@ 2019-09-17 15:03 ` arnold
0 siblings, 0 replies; 103+ messages in thread
From: arnold @ 2019-09-17 15:03 UTC (permalink / raw)
To: clemc, arnold; +Cc: tuhs
Yes, I think the next time anyone says anything about markup languages,
I'll just use private mail.
Thanks,
Arnold
Clem Cole <clemc@ccc.com> wrote:
> Fair enough. Mei culpa from one of those that was vocal. That said, maybe
> a trick is to stay away from texinfo/info and the man page discussion on
> this list since its a hot button that causes much trama for some with a
> more traditional UNIX view.
>
> Please don't leave, your voice is important and I generally agree with you
> and always like to hear you out. But even if I do not agree, I still want
> to listen. You have come to your conclusions in a different manner than
> some of us, and where each of us puts the MSB tends to color our views.
> Diversity of opinion is a good thing.
>
> Respectfully,
> Clem
> ᐧ
>
> On Tue, Sep 17, 2019 at 3:53 AM <arnold@skeeve.com> wrote:
>
> > It is like clockwork.
> >
> > Whenever I say something about Texinfo *as a markup language* for use
> > in *writing books*, the discussion inevitably degenerates into a hate
> > rant against Info and RMS's (failed) attempt to replace man pages.
> > Totally missing the point too.
> >
> > This is a trend on TUHS. The same discussions, the same rants, often
> > the same misinformation, over and over and over again.
> >
> > I start to wonder if I should continue to subscribe.
> >
> > Arnold
> >
> > Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> > > > On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
> > > >
> > > > > I use the standalone Info reader (named info) if I want to look at
> > the
> > > > > Info output.
> > > > >
> > > > Fair enough, but be careful, while I admit I have not looked in a
> > while,
> > > > info(gnu) relies on emacs keybindings and a number of very emacs'ish
> > things.
> > > > Every time I have tried to deal with it, I have unprogram my fingers
> > and
> > > > reset them to emacs.
> > > >
> > > > If it would have used more(1) [or even less(1)] then I would not be as
> > > > annoyed.
> > > > Unix had fine tools [man(1), more(1), et al] and rms and friends felt
> > the
> > > > need to replace them with ITS-like programs.
> > >
> > > I hate texinfo and friends. I get why it is better than man, but man was
> > > good enough, more than good enough, and the GNU project took everything
> > > it could find and destroyed the man pages.
> > >
> > > If you have something like perl that needs a zillion sub pages, info
> > > makes sense. For just a man page, info is horrible.
> >
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 7:53 ` arnold
2019-09-17 14:21 ` Clem Cole
@ 2019-09-17 15:58 ` Christopher Browne
2019-09-17 18:15 ` arnold
1 sibling, 1 reply; 103+ messages in thread
From: Christopher Browne @ 2019-09-17 15:58 UTC (permalink / raw)
To: arnold, The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
On Tue, Sep 17, 2019, 3:54 AM <arnold@skeeve.com> wrote:
> It is like clockwork.
>
> Whenever I say something about Texinfo *as a markup language* for use
> in *writing books*, the discussion inevitably degenerates into a hate
> rant against Info and RMS's (failed) attempt to replace man pages.
> Totally missing the point too.
>
Yeah, that is a pain in the neck.
I had the other reaction to this...
I have been managing my web presence via DocBook SGML for a goodly long
time. It is, as mentioned upthread, pretty wordy what with all the verbose
tagging.
It would be worth something to be able to edit it in TeXinfo form, with the
lesser amount of tagging required. (And I'd kinda like to get off of
DocBook/SGML one of these days as the toolset is clearly mouldering away
pretty badly.)
So my reaction to your comments was to look into the usability of
TeXinfo... I did a wee experiment yesterday, attempting to use docbook2x
to get to something else. Alas, it seems to want to use xsltproc on the
XML form, and the transformation to XML is apparently a separate pain in
the neck. I thought I accomplished it, but the XSLT for generating TeXinfo
throws up on it, so there must be more to the matter. I'll take a further
poke at it later; thank you for offering a bit of inspiration on possible
approaches to change.
I know I can turn DocBook into s-expressions, and then write some
transformation in CL after that; it would be nice if there were something
already written.
For sophisticated material, TeXinfo is of use, notwithstanding notions to
make everything into brief man pages.
Bashing RMS for wanting things from ITS (and probably Multics too) (as I
see elsewhere in the thread) is unnecessarily unkind. A dogmatic attitude
of "must be short man pages" shifts us to a different Procrustean bed that
fails in a different set of cases. I for one was kinda hoping for Project
Xanadu someday, to throw a different perspective on that.
>
[-- Attachment #2: Type: text/html, Size: 2867 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 15:58 ` Christopher Browne
@ 2019-09-17 18:15 ` arnold
2019-09-17 18:32 ` Warner Losh
2019-09-18 0:42 ` Adam Thornton
0 siblings, 2 replies; 103+ messages in thread
From: arnold @ 2019-09-17 18:15 UTC (permalink / raw)
To: tuhs, cbbrowne, arnold
Hi.
Christopher Browne <cbbrowne@gmail.com> wrote:
> I had the other reaction to this...
>
> I have been managing my web presence via DocBook SGML for a goodly long
> time. It is, as mentioned upthread, pretty wordy what with all the verbose
> tagging.
>
> It would be worth something to be able to edit it in TeXinfo form, with the
> lesser amount of tagging required. (And I'd kinda like to get off of
> DocBook/SGML one of these days as the toolset is clearly mouldering away
> pretty badly.)
Looks like pandoc will go from DocBook to Texinfo.
Me, I'd probably write a giant awk script to do the grunt work. :-)
> For sophisticated material, TeXinfo is of use, notwithstanding notions to
> make everything into brief man pages.
As I've been saying, I use it for books.
Good luck,
Arnold
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 18:15 ` arnold
@ 2019-09-17 18:32 ` Warner Losh
2019-09-18 0:42 ` Adam Thornton
1 sibling, 0 replies; 103+ messages in thread
From: Warner Losh @ 2019-09-17 18:32 UTC (permalink / raw)
To: Arnold Robbins; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
On Tue, Sep 17, 2019 at 12:16 PM <arnold@skeeve.com> wrote:
> Hi.
>
> Christopher Browne <cbbrowne@gmail.com> wrote:
> > I had the other reaction to this...
> >
> > I have been managing my web presence via DocBook SGML for a goodly long
> > time. It is, as mentioned upthread, pretty wordy what with all the
> verbose
> > tagging.
> >
> > It would be worth something to be able to edit it in TeXinfo form, with
> the
> > lesser amount of tagging required. (And I'd kinda like to get off of
> > DocBook/SGML one of these days as the toolset is clearly mouldering away
> > pretty badly.)
>
> Looks like pandoc will go from DocBook to Texinfo.
>
> Me, I'd probably write a giant awk script to do the grunt work. :-)
>
FreeBSD likely is moving out DocBook stuff to markdown. Docbook is too hard
to find people to work on :(
Warner
[-- Attachment #2: Type: text/html, Size: 1334 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-17 18:15 ` arnold
2019-09-17 18:32 ` Warner Losh
@ 2019-09-18 0:42 ` Adam Thornton
1 sibling, 0 replies; 103+ messages in thread
From: Adam Thornton @ 2019-09-18 0:42 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
I always rather liked the IBM Bookmaster flavor of GML. I wrote some
good-looking (and perhaps even useful) things in it.
Adam
On Tue, Sep 17, 2019 at 11:16 AM <arnold@skeeve.com> wrote:
> Hi.
>
> Christopher Browne <cbbrowne@gmail.com> wrote:
> > I had the other reaction to this...
> >
> > I have been managing my web presence via DocBook SGML for a goodly long
> > time. It is, as mentioned upthread, pretty wordy what with all the
> verbose
> > tagging.
> >
> > It would be worth something to be able to edit it in TeXinfo form, with
> the
> > lesser amount of tagging required. (And I'd kinda like to get off of
> > DocBook/SGML one of these days as the toolset is clearly mouldering away
> > pretty badly.)
>
> Looks like pandoc will go from DocBook to Texinfo.
>
> Me, I'd probably write a giant awk script to do the grunt work. :-)
>
> > For sophisticated material, TeXinfo is of use, notwithstanding notions to
> > make everything into brief man pages.
>
> As I've been saying, I use it for books.
>
> Good luck,
>
> Arnold
>
[-- Attachment #2: Type: text/html, Size: 1549 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:10 ` Clem Cole
` (2 preceding siblings ...)
2019-09-16 14:51 ` Larry McVoy
@ 2019-09-16 21:42 ` Dave Horsfall
2019-09-16 21:48 ` Larry McVoy
2019-09-17 0:16 ` Greg 'groggy' Lehey
2019-10-05 19:44 ` Michael Parson
4 siblings, 2 replies; 103+ messages in thread
From: Dave Horsfall @ 2019-09-16 21:42 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
On Mon, 16 Sep 2019, Clem Cole wrote:
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very
> emacs'ish things. Every time I have tried to deal with it, I have
> unprogram my fingers and reset them to emacs.
Yep, which is why I like "info" as much as I like EMACS i.e. not at all.
What exactly is wrong with the manpage format? It tells you everything
you need to know, and tells you where to find further information.
-- Dave
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 21:42 ` Dave Horsfall
@ 2019-09-16 21:48 ` Larry McVoy
2019-09-16 21:54 ` Jon Steinhart
2019-09-17 0:16 ` Greg 'groggy' Lehey
1 sibling, 1 reply; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 21:48 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
On Tue, Sep 17, 2019 at 07:42:28AM +1000, Dave Horsfall wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
>
> >Fair enough, but be careful, while I admit I have not looked in a while,
> >info(gnu) relies on emacs keybindings and a number of very
> >emacs'ish??things. Every time I have tried to deal with it, I have
> >unprogram my fingers and reset them to emacs.
>
> Yep, which is why I like "info" as much as I like EMACS i.e. not at all.
>
> What exactly is wrong with the manpage format? It tells you everything you
> need to know, and tells you where to find further information.
I think, someone correct me if I'm wrong, the info stuff was designed
to handle larger, more complex stuff, with a table of contents, etc.
Something like perl could fit in one info doc but the perl man page is
not a thing, it's just a series of pointers to more man pages.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 21:48 ` Larry McVoy
@ 2019-09-16 21:54 ` Jon Steinhart
2019-09-16 21:59 ` Larry McVoy
2019-09-16 22:10 ` Bakul Shah
0 siblings, 2 replies; 103+ messages in thread
From: Jon Steinhart @ 2019-09-16 21:54 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Larry McVoy writes:
>
> I think, someone correct me if I'm wrong, the info stuff was designed
> to handle larger, more complex stuff, with a table of contents, etc.
> Something like perl could fit in one info doc but the perl man page is
> not a thing, it's just a series of pointers to more man pages.
Can't answer you directly on this one, but I prefer the old system of
having man pages and separate documents for longer things. I still
have old notebooks full of papers on lex, yacc, and so on.
One of the problems with using info for something like perl is that it
doesn't have a useful organization. There's a difference to me between
a reference manual and a user's guide. Most of the stuff referenced by
the main perl page is user's guide stuff to me, it's not a reference.
Probably someone knows more than me about all this. I have always been
under the impression that one read the user's guide to learn about
complicated stuff. The manual pages were there so that you could find
the right options when you forgot. Putting every detail about a complex
program into a manual page doesn't feel right to me.
Jon
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 21:54 ` Jon Steinhart
@ 2019-09-16 21:59 ` Larry McVoy
2019-09-17 5:07 ` Lars Brinkhoff
2019-09-16 22:10 ` Bakul Shah
1 sibling, 1 reply; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 21:59 UTC (permalink / raw)
To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 02:54:49PM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
>
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things. I still
> have old notebooks full of papers on lex, yacc, and so on.
>
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization.
We are 100% on the same page. My complaint about wikis is it is impossible
to find anything without a search engine. I like tables of contents and
indices.
My comment on the info stuff was just my understand of why it came to be.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 21:59 ` Larry McVoy
@ 2019-09-17 5:07 ` Lars Brinkhoff
0 siblings, 0 replies; 103+ messages in thread
From: Lars Brinkhoff @ 2019-09-17 5:07 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
Larry McVoy wrote:
> My comment on the info stuff was just my understand of why it came to be.
Probably no one knows any more.
Quick history recap:
- First there was the old plain text INFO which was more like Unix' man.
- Then there was the new hypertext INFO built on EMACS.
- GNU info copied ITS' INFO.
When I ask ITS people about this old plain text INFO, they don't even
remember it.
I think it's reasonable to assume they thought the new hypertext format
with links was more intriguing technology than plain text files.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 21:54 ` Jon Steinhart
2019-09-16 21:59 ` Larry McVoy
@ 2019-09-16 22:10 ` Bakul Shah
1 sibling, 0 replies; 103+ messages in thread
From: Bakul Shah @ 2019-09-16 22:10 UTC (permalink / raw)
To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society
On Mon, 16 Sep 2019 14:54:49 -0700 Jon Steinhart <jon@fourwinds.com> wrote:
> Larry McVoy writes:
> >
> > I think, someone correct me if I'm wrong, the info stuff was designed
> > to handle larger, more complex stuff, with a table of contents, etc.
> > Something like perl could fit in one info doc but the perl man page is
> > not a thing, it's just a series of pointers to more man pages.
>
> Can't answer you directly on this one, but I prefer the old system of
> having man pages and separate documents for longer things. I still
> have old notebooks full of papers on lex, yacc, and so on.
>
> One of the problems with using info for something like perl is that it
> doesn't have a useful organization. There's a difference to me between
> a reference manual and a user's guide. Most of the stuff referenced by
> the main perl page is user's guide stuff to me, it's not a reference.
>
> Probably someone knows more than me about all this. I have always been
> under the impression that one read the user's guide to learn about
> complicated stuff. The manual pages were there so that you could find
> the right options when you forgot. Putting every detail about a complex
> program into a manual page doesn't feel right to me.
A typical manpage had just the right length. Reading man pages
and experimenting is how I initially learned all about unix
commands.
Keeping a manpage short also limited what you as the
implementer would be tempted to add to the command. Manpages
work best for programs that follow the unix mantra of do one
thing and do it well. But not for kitchensink programs. When
you need a multipage reference manual (for *experts*) with a
TOC and program to "navigate", you're much more likely to give
into the temptation of adding more features than partition
functionality into separate programs that work well together.
Not to mention it is harder to get something right that has
many more features.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 21:42 ` Dave Horsfall
2019-09-16 21:48 ` Larry McVoy
@ 2019-09-17 0:16 ` Greg 'groggy' Lehey
2019-09-17 0:31 ` Jon Steinhart
2019-09-17 12:20 ` David
1 sibling, 2 replies; 103+ messages in thread
From: Greg 'groggy' Lehey @ 2019-09-17 0:16 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
On Tuesday, 17 September 2019 at 7:42:28 +1000, Dave Horsfall wrote:
> On Mon, 16 Sep 2019, Clem Cole wrote:
>
>> Fair enough, but be careful, while I admit I have not looked in a while,
>> info(gnu) relies on emacs keybindings and a number of very
>> emacs'ish things. Every time I have tried to deal with it, I have
>> unprogram my fingers and reset them to emacs.
>
> Yep, which is why I like "info" as much as I like EMACS i.e. not at
> all.
Maybe I've missed something, but I'm in the intermediate camp. Emacs
is in my fingertips, and I wouldn't want to live without it, but I'd
far rather see info go away. In some ways it anticipated HTML, but I
find navigation particularly painful.
> What exactly is wrong with the manpage format?
It's linear.
> It tells you everything you need to know, and tells you where to
> find further information.
Yes, but you need to follow the link manually. Theoretically a good
HTML document would be better, but it's nice to have a linear form
that you can search.
For an extreme case of man pages, look at something like mplayer(1) or
mpv(1):
$ man mplayer|wc -l
9435
$ man mpv|wc -l
13939
That doesn't make them easy to read.
Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:10 ` Clem Cole
` (3 preceding siblings ...)
2019-09-16 21:42 ` Dave Horsfall
@ 2019-10-05 19:44 ` Michael Parson
4 siblings, 0 replies; 103+ messages in thread
From: Michael Parson @ 2019-10-05 19:44 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
(pardon the reply on an oldish thread, I've not read this group in a
while)
On Mon, 16 Sep 2019, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
>
>> I use the standalone Info reader (named info) if I want to look at the
>> Info output.
>>
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
>
> If it would have used more(1) [or even less(1)] then I would not be as
> annoyed.
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> need to replace them with ITS-like programs.
A few years ago, I was introduced to pinfo[0] for reading info pages, it's
more like using the lynx browser to read info docs rather than the emacs
keybindings.
--
Michael Parson
Pflugerville, TX
KF5LGQ
[0] http://pinfo.sourceforge.net
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 2:56 ` U'll Be King of the Stars
2019-09-15 6:54 ` arnold
@ 2019-09-15 19:35 ` Clem Cole
2019-09-15 20:49 ` U'll Be King of the Stars
1 sibling, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-15 19:35 UTC (permalink / raw)
To: U'll Be King of the Stars; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars <
ullbeking@andrewnesbit.org> wrote:
>
> I've been wondering whether it is possible and worthwhile to use *roff
> for complex technical documentation. I've always loved the aesthetic
> that books produced using *roff have but there are other reasons too.
>
Ditto. The books that used roff can look clean and within a series are
usually consistent, but what I've like is that they are different.
The Prentiss-Hall series and the ORA books both were produced using troff
and different versions of ms, but the results are different.
One of my complained with LaTex books is they all seem to look the same.
> Getting back to *roff, does anybody know if there is a (hopefully rich)
> repository of macros, or any other resources, for my use case?
>
I've never seen one. As far as I knew it, publishers sometimes seeded
authors. ORA used the Masscomp/Tektronix derived version of ms (-mS) that
Steve Talbot created (and Rick LeFaivre originally created from the
original Lesk V7 set). Rich Steven's has his own additions to the version
of ms that came with groff which I have also seen.
[-- Attachment #2: Type: text/html, Size: 2314 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 19:35 ` Clem Cole
@ 2019-09-15 20:49 ` U'll Be King of the Stars
2019-09-16 6:20 ` arnold
0 siblings, 1 reply; 103+ messages in thread
From: U'll Be King of the Stars @ 2019-09-15 20:49 UTC (permalink / raw)
To: Clem Cole, The Eunuchs Hysterical Society
On 15/09/2019 20:35, Clem Cole wrote:
>
>
> On Sat, Sep 14, 2019 at 11:03 PM U'll Be King of the Stars
> <ullbeking@andrewnesbit.org <mailto:ullbeking@andrewnesbit.org>> wrote:
>
>
> I've been wondering whether it is possible and worthwhile to use *roff
> for complex technical documentation. I've always loved the aesthetic
> that books produced using *roff have but there are other reasons too.
>
> Ditto. The books that used roff can look clean and within a series are
> usually consistent, but what I've like is that they are different.
Yes, they look clean but different to each other.
I'm guessing that the reason might be that it is easier to exercise
*roff's capabilities than it is to push LaTeX to get good results
without spending a huge amount of time.
> The Prentiss-Hall series and the ORA books both were produced using
> troff and different versions of ms, but the results are different.
I wonder if Prentice-Hall and O'Reilly & Associates might be willing to
share their *roff macro sets in an open source way.
> One of my complained with LaTex books is they all seem to look the same.
Don't they ever?! It has gotten to the point that Computer Modern
actually makes me feel *fatigued* when I encounter it when reading, say,
a mathematics monograph.
On the other hand it's the perfect typeface for résumés and CV's for
computer scientists. Like a secret handshake.
Perhaps the reason that the CM typeface is so common is that changing
typefaces in LaTeX is complicated and difficult so authors leave it
alone. At least this has been my experience.
> Getting back to *roff, does anybody know if there is a (hopefully rich)
> repository of macros, or any other resources, for my use case?
>
> I've never seen one. As far as I knew it, publishers sometimes seeded
> authors. ORA used the Masscomp/Tektronix derived version of ms (-mS)
> that Steve Talbot created (and Rick LeFaivre originally created from the
> original Lesk V7 set). Rich Steven's has his own additions to the
> version of ms that came with groff which I have also seen.
This is fascinating insider information, and it leads me full circle to
several reasons why I want to try to use *roff in the first place:
1. Do you think there is any chance of obtaining these macro packages?
Either from authors who haven't passed away, or from the publishing
houses themselves?
2. I get the impression that writing a macro package or editing an
existing is relatively straightforward. Would you agree?
Or, at least, that it makes some kind of sense. I could never make
head or tail of LaTeX's macro extensions. I certainly didn't want to
spend my life trying to figure it out.
I still remember the sinking feeling in my stomach when I realized
that the five (or so) books that make up the de facto canon of LaTeX
user documentation (published by Addison-Wesley) are thousands of pages
in total. I did not want to engage with that.
I have no particular intention to speak ill of LaTeX. Rather, it is my
only point of reference for publishing-grade typesetting and
unfortunately I don't have fond memories of it.
Kind regards,
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 20:49 ` U'll Be King of the Stars
@ 2019-09-16 6:20 ` arnold
2019-09-16 12:13 ` Clem Cole
0 siblings, 1 reply; 103+ messages in thread
From: arnold @ 2019-09-16 6:20 UTC (permalink / raw)
To: ullbeking, tuhs, clemc
"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:
> This is fascinating insider information, and it leads me full circle to
> several reasons why I want to try to use *roff in the first place:
>
> 1. Do you think there is any chance of obtaining these macro packages?
> Either from authors who haven't passed away, or from the publishing
> houses themselves?
O'Reilly probably would. I can ask someone there, if there's serious
interest here. They haven't used troff for book production for well
over a decade.
I'm not sure that Prentice-Hall had its own macros. Rather, the
books from Bell Labs were all set on the same research Unix systems.
> 2. I get the impression that writing a macro package or editing an
> existing is relatively straightforward. Would you agree?
Possibly straightforward, but very much like working in assembly
language. The commands and escape sequences (in standard troff) are
all very short, and thus cryptic, and the extra levels of backslashes
needed inside macro bodies don't help.
GNU troff has additional features that probably help a lot; my experience
has been in grunging around in traditional packages.
My two cents,
Arnodl
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 6:20 ` arnold
@ 2019-09-16 12:13 ` Clem Cole
2019-09-16 12:34 ` arnold
2019-09-16 14:52 ` Larry McVoy
0 siblings, 2 replies; 103+ messages in thread
From: Clem Cole @ 2019-09-16 12:13 UTC (permalink / raw)
To: Aharon Robbins; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote:
> I'm not sure that Prentice-Hall had its own macros. Rather, the
> books from Bell Labs were all set on the same research Unix systems.
>
That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
Comer's books. I know for fact that Rich had a set of macro's (based
originally on -ms) and a set of integrated makefiles to build his texts. I
was under the impression he passed them to a number of people, not just
people like me.
[-- Attachment #2: Type: text/html, Size: 1030 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:13 ` Clem Cole
@ 2019-09-16 12:34 ` arnold
2019-09-16 14:52 ` Larry McVoy
1 sibling, 0 replies; 103+ messages in thread
From: arnold @ 2019-09-16 12:34 UTC (permalink / raw)
To: clemc, arnold; +Cc: tuhs
Clem Cole <clemc@ccc.com> wrote:
> On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote:
>
> > I'm not sure that Prentice-Hall had its own macros. Rather, the
> > books from Bell Labs were all set on the same research Unix systems.
> >
> That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
> Comer's books. I know for fact that Rich had a set of macro's (based
> originally on -ms) and a set of integrated makefiles to build his texts. I
> was under the impression he passed them to a number of people, not just
> people like me.
Don't know, but you could try http://www.unixnetworkprogramming.com/contact.html
for the Unix Network Programming book which was updated after Richard
Stevens passed away.
Arnold
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 12:13 ` Clem Cole
2019-09-16 12:34 ` arnold
@ 2019-09-16 14:52 ` Larry McVoy
1 sibling, 0 replies; 103+ messages in thread
From: Larry McVoy @ 2019-09-16 14:52 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 08:13:55AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 2:21 AM <arnold@skeeve.com> wrote:
>
> > I'm not sure that Prentice-Hall had its own macros. Rather, the
> > books from Bell Labs were all set on the same research Unix systems.
> >
> That's might be true for bwk's and Pike's stuff, but not Rich Steven's or
> Comer's books. I know for fact that Rich had a set of macro's (based
> originally on -ms) and a set of integrated makefiles to build his texts. I
> was under the impression he passed them to a number of people, not just
> people like me.
I don't have them but he and I had many discussions about troff, tbl,
pic, etc. We had a shared love for pic.
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-14 2:44 ` Warren Toomey
2019-09-15 2:56 ` U'll Be King of the Stars
@ 2019-09-15 19:27 ` Clem Cole
2019-09-15 19:31 ` Jon Steinhart
1 sibling, 1 reply; 103+ messages in thread
From: Clem Cole @ 2019-09-15 19:27 UTC (permalink / raw)
To: Warren Toomey; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
Warren,
On Fri, Sep 13, 2019 at 10:44 PM Warren Toomey <wkt@tuhs.org> wrote:
>
> Here's a good page on the history:
> https://manpages.bsd.lv/history.html
Excellent - thanks for the pointer. This shows nroff before troff.
FWIW: I guess I was miss informed, but I had been under the impression
that was the other way around. i.e. nroff was done to be compliant with
the new troff, replacing roff, although the suggestion here is that he
wrote it add macros to roff. I'll note that either way, the dates are all
possible of course because the U/L case ASR 37 was introduced 1968 so by
the early 1970's they would have been around the labs.
[-- Attachment #2: Type: text/html, Size: 1225 bytes --]
^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-15 19:27 ` Clem Cole
@ 2019-09-15 19:31 ` Jon Steinhart
0 siblings, 0 replies; 103+ messages in thread
From: Jon Steinhart @ 2019-09-15 19:31 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Clem Cole writes:
> Excellent - thanks for the pointer. This shows nroff before troff.
> FWIW: I guess I was miss informed, but I had been under the impression
> that was the other way around. i.e. nroff was done to be compliant with
> the new troff, replacing roff, although the suggestion here is that he
> wrote it add macros to roff. I'll note that either way, the dates are all
> possible of course because the U/L case ASR 37 was introduced 1968 so by
> the early 1970's they would have been around the labs.
Yes, we had ASR 37s, used one myself. Not only did the do upper and lower
case, but they also did Greek and math characters, had bracket building
characters, and so on. Biggest problem was line noise since these were
mostly on dial-up. One could be having a nice day and all of a sudden a
burst of line noise would trigger a shift-out and everything would be
gibberish.
^ permalink raw reply [flat|nested] 103+ messages in thread
end of thread, other threads:[~2019-10-05 20:01 UTC | newest]
Thread overview: 103+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-15 22:07 [TUHS] earliest Unix roff Doug McIlroy
2019-09-17 0:20 ` Steve Johnson
2019-09-17 1:11 ` Arthur Krewat
2019-09-17 1:17 ` Larry McVoy
2019-09-17 1:26 ` Clem cole
2019-09-17 1:33 ` Larry McVoy
2019-09-17 22:39 ` Dave Horsfall
2019-09-17 1:36 ` Richard Salz
2019-09-17 1:36 ` [TUHS] wizards test [was roff] Clem cole
2019-09-17 1:38 ` Clem cole
2019-09-17 2:34 ` Larry McVoy
2019-09-17 1:57 ` [TUHS] earliest Unix roff Bakul Shah
2019-09-17 1:11 ` [TUHS] Model 37's Ronald Natalie
2019-09-17 1:19 ` [TUHS] earliest Unix roff Bakul Shah
-- strict thread matches above, loose matches on Subject: below --
2019-09-19 18:50 [TUHS] [OT] " Norman Wilson
2019-09-19 19:00 ` Nemo Nusquam
2019-09-19 20:18 ` Larry McVoy
2019-09-19 20:42 ` [TUHS] " Andy Kosela
2019-09-19 18:42 Norman Wilson
2019-09-19 22:42 ` Rob Pike
2019-09-19 22:55 ` Bakul Shah
2019-09-19 18:10 Norman Wilson
2019-09-19 18:37 ` Clem Cole
2019-09-19 18:44 ` Jon Steinhart
2019-09-19 19:44 ` Steffen Nurpmeso
2019-09-19 20:38 ` John P. Linderman
2019-09-20 13:41 ` Steffen Nurpmeso
2019-09-20 15:03 ` Steffen Nurpmeso
2019-09-19 20:53 ` Bakul Shah
2019-09-15 2:45 Doug McIlroy
2019-09-13 3:20 [TUHS] My EuroBSDcon talk (preview for commentary) Warner Losh
2019-09-13 19:47 ` Clem Cole
2019-09-13 20:02 ` Clem Cole
2019-09-13 20:06 ` Clem Cole
2019-09-13 20:24 ` Jon Steinhart
2019-09-13 20:43 ` Clem Cole
2019-09-13 20:53 ` Diomidis Spinellis
2019-09-13 21:45 ` Clem Cole
2019-09-13 22:13 ` [TUHS] earliest Unix roff Warren Toomey
2019-09-13 22:55 ` Clem Cole
2019-09-14 2:02 ` Larry McVoy
2019-09-14 2:44 ` Warren Toomey
2019-09-15 2:56 ` U'll Be King of the Stars
2019-09-15 6:54 ` arnold
2019-09-15 7:01 ` Dave Horsfall
2019-09-15 16:17 ` Jon Steinhart
2019-09-15 17:23 ` Ronald Natalie
2019-09-15 19:48 ` Clem Cole
2019-09-15 21:16 ` Dave Horsfall
2019-09-15 7:32 ` U'll Be King of the Stars
2019-09-15 7:46 ` arnold
2019-09-15 19:37 ` Clem Cole
2019-09-16 5:52 ` arnold
2019-09-16 12:10 ` Clem Cole
2019-09-16 12:26 ` Lars Brinkhoff
2019-09-16 13:42 ` Clem Cole
2019-09-16 14:54 ` Larry McVoy
2019-09-16 16:09 ` Paul Winalski
2019-09-16 22:05 ` Dave Horsfall
2019-09-16 22:33 ` reed
2019-09-17 0:11 ` Dave Horsfall
2019-09-17 0:02 ` Nemo Nusquam
2019-09-17 0:21 ` Arthur Krewat
2019-09-17 11:12 ` Thomas Paulsen
2019-09-17 0:46 ` Clem Cole
2019-09-16 13:13 ` Chet Ramey
2019-09-16 14:51 ` Larry McVoy
2019-09-16 14:57 ` Clem Cole
2019-09-16 15:14 ` Richard Salz
2019-09-16 15:48 ` Ronald Natalie
2019-09-16 16:10 ` Larry McVoy
2019-09-16 16:16 ` Jon Steinhart
2019-09-16 16:26 ` Larry McVoy
2019-09-16 16:31 ` Richard Salz
2019-09-16 16:45 ` Larry McVoy
2019-09-16 17:19 ` KatolaZ
2019-09-16 17:24 ` Larry McVoy
2019-09-16 17:32 ` Jon Steinhart
2019-09-16 17:35 ` Clem Cole
2019-09-16 17:37 ` Jon Steinhart
2019-09-16 18:04 ` Chet Ramey
2019-09-16 18:19 ` KatolaZ
2019-09-16 23:24 ` Dave Horsfall
2019-09-16 17:24 ` Clem Cole
2019-09-16 17:00 ` Clem Cole
2019-09-17 11:20 ` Thomas Paulsen
2019-09-16 19:13 ` Steffen Nurpmeso
2019-09-16 19:31 ` Bakul Shah
2019-09-16 22:35 ` Dave Horsfall
2019-09-17 7:53 ` arnold
2019-09-17 14:21 ` Clem Cole
2019-09-17 15:03 ` arnold
2019-09-17 15:58 ` Christopher Browne
2019-09-17 18:15 ` arnold
2019-09-17 18:32 ` Warner Losh
2019-09-18 0:42 ` Adam Thornton
2019-09-16 21:42 ` Dave Horsfall
2019-09-16 21:48 ` Larry McVoy
2019-09-16 21:54 ` Jon Steinhart
2019-09-16 21:59 ` Larry McVoy
2019-09-17 5:07 ` Lars Brinkhoff
2019-09-16 22:10 ` Bakul Shah
2019-09-17 0:16 ` Greg 'groggy' Lehey
2019-09-17 0:31 ` Jon Steinhart
2019-09-17 12:20 ` David
2019-10-05 19:44 ` Michael Parson
2019-09-15 19:35 ` Clem Cole
2019-09-15 20:49 ` U'll Be King of the Stars
2019-09-16 6:20 ` arnold
2019-09-16 12:13 ` Clem Cole
2019-09-16 12:34 ` arnold
2019-09-16 14:52 ` Larry McVoy
2019-09-15 19:27 ` Clem Cole
2019-09-15 19:31 ` Jon Steinhart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).