The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* 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] 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  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  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] 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] 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] 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: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] 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] 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: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-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-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 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-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: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 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-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 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 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 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: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: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: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-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-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 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  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 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: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  0:16                                   ` Greg 'groggy' Lehey
  2019-09-17  0:31                                     ` Jon Steinhart
@ 2019-09-17 12:20                                     ` David
  1 sibling, 0 replies; 103+ messages in thread
From: David @ 2019-09-17 12:20 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: The Eunuchs Hysterical Society


> On Sep 16, 2019, at 5:16 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> 
> 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
> 
Those aren’t man pages, they are novellas.

	David


^ 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-17  0:02                                       ` Nemo Nusquam
  2019-09-17  0:21                                         ` Arthur Krewat
@ 2019-09-17 11:12                                         ` Thomas Paulsen
  1 sibling, 0 replies; 103+ messages in thread
From: Thomas Paulsen @ 2019-09-17 11:12 UTC (permalink / raw)
  To: Nemo Nusquam; +Cc: tuhs



Nemo Nusquam wrote:
> 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).
the sources can be found at Jorg Schillings sourceforge site.



^ 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-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 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-17  0:16                                   ` Greg 'groggy' Lehey
@ 2019-09-17  0:31                                     ` Jon Steinhart
  2019-09-17 12:20                                     ` David
  1 sibling, 0 replies; 103+ messages in thread
From: Jon Steinhart @ 2019-09-17  0:31 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Greg 'groggy' Lehey writes:
>
> 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.

Isn't "good HTML document" an oxymoron?

^ permalink raw reply	[flat|nested] 103+ messages in thread

* Re: [TUHS] earliest Unix roff
  2019-09-17  0:02                                       ` Nemo Nusquam
@ 2019-09-17  0:21                                         ` Arthur Krewat
  2019-09-17 11:12                                         ` Thomas Paulsen
  1 sibling, 0 replies; 103+ messages in thread
From: Arthur Krewat @ 2019-09-17  0:21 UTC (permalink / raw)
  To: tuhs

On 9/16/2019 8:02 PM, Nemo Nusquam wrote:
> 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).

Now you've gone and said a bad word... ;)

art k.


^ 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 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 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 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 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 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 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 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: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: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 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 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 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 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 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 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: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: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 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 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 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 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: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: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: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: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 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 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 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 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 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 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 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-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 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 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: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: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  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  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-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-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-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 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  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  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  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: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

* 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 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 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  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  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  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  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-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: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

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

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