Unix V10 Volume 2 PDFs

Unix V10 Volume 2 PDFs

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Hi наб!

Just wondering...  why not build a new PDF from source, instead of
scanning the book?  Doesn't groff(1) handle the Unix sources?  I expect
the answer is not licenses (because I expect redistributing the scanned
original will be as bad as generating an apocryphal PDF in terms of
licensing).  I sometimes wondered if I should run the Linux man-pages
build system on the sources of Unix manual pages to generate an
apocryphal PDF book of Volume 1 of the different Unix systems.  I never
ended up doing so for fear of AT&T lawyers (or whoever owns the rights
to their manuals today), but I find it would be useful.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Unix V10 Volume 2 PDFs

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 4229 bytes --]

[looping in TUHS so my historical mistakes can be corrected]

Hi Alex,

At 2025-02-13T00:59:33+0100, Alejandro Colomar wrote:
> Just wondering...  why not build a new PDF from source, instead of
> scanning the book?

A.  I don't think we know for sure which version of troff was used to
    format the V10 manual.  _Probably_ Kernighan's research version,
    which was similar to a contemporaneous DWB troff...but what
    "contemporaneous" means in the 1989-1990 period is a little fuzzy.
    Also, Kernighan may not have a complete source history of his
    version of troff, it is presumably still encumbered by AT&T
    copyrights, and he's been using groff for at least his last two
    books (his Unix memoir and the 2nd edition of the AWK book).

B.  It is hard to recreate a Research Unix V10 installation.  My
    understanding is that Unix V8-V10 were not full distributions but
    patches.  And because troff was commercial/proprietary software at
    that (the aforementioned DWB troff), I don't know if Kernighan's
    "Research troff" escaped Bell Labs or how consistently it could be
    expected to be present on a system.  Presumably any of a variety of
    DWB releases would have "worked fine".  How much they would have
    varied in extremely fiddly details of typesetting is an open
    question.  I can say with some confidence that the mm package saw
    fairly significant development.  Of troff itself (and the
    preprocessors one bumps into in the Volume 2 white papers) I'm much
    more in the dark.

C.  Getting a scan out there tells us at least what one software
    configuration deemed acceptable by producers of the book generated,
    even if it's impossible to identify details of that software
    configuration.  That in turn helps us to judge the results of
    _known_ software configurations--groff, and other troffs too.

D.  troff is not TeX.  Nothing like trip.tex has ever existed.  A golden
    platonic ideal of formatter behavior does not exist except in the
    collective, sometimes contentious minds of its users.

> Doesn't groff(1) handle the Unix sources?

Assuming the full source of a document is available, and no part of its
toolchain requires software that is unavailable (like Van Wyk's "ideal"
preprocessor) then if groff cannot satisfactorily render a document
produced by the Bell Labs CSRC, then I'd consider that presumptively a
bug in groff.  It's a rebuttable presumption--if one document in one
place relied upon a _bug_ in AT&T troff to produce correct rendering, I
think my inclination would be to annotate the problem somewhere in
groff's documentation and leave it unresolved.

For a case where groff formats a classic Unix document "better" (in
the sense of not unintentionally omitting a formatted equation) than
AT&T troff, see the following.

https://github.com/g-branden-robinson/retypesetting-mathematics

> I expect the answer is not licenses (because I expect redistributing
> the scanned original will be as bad as generating an apocryphal PDF in
> terms of licensing).

I've opined before that the various aspects of Unix "IP" ownership
appear to be so complicated and mired in the details of decades-old
contracts in firms that have changed ownership structures multiple
times, that legally valid answers to questions like this may not exist.
Not until a firm that thinks it holds the rights decides it's worth the
money to pay a bunch of archivists and copyright attorneys to go on a
snipe hunt.

And that decision won't be made unless said firm thinks the probability
is high that they can recover damages from infringers in excess of their
costs.  Otherwise the decision simply sets fire to a pile of money.

...which isn't impossible.  Billionaires do it every day.

> I sometimes wondered if I should run the Linux man-pages build system
> on the sources of Unix manual pages to generate an apocryphal PDF book
> of Volume 1 of the different Unix systems.  I never ended up doing so
> for fear of AT&T lawyers (or whoever owns the rights to their manuals
> today), but I find it would be useful.

It's the kind of thing I've thought about doing.  :)

If you do, I very much want to know if groff appears to misbehave.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [TUHS] Re: Unix V10 Volume 2 PDFs

[Larry McVoy]

On Wed, Feb 12, 2025 at 07:21:07PM -0600, G. Branden Robinson wrote:
> > Doesn't groff(1) handle the Unix sources?
> 
> Assuming the full source of a document is available, and no part of its
> toolchain requires software that is unavailable (like Van Wyk's "ideal"
> preprocessor) then if groff cannot satisfactorily render a document
> produced by the Bell Labs CSRC, then I'd consider that presumptively a
> bug in groff.  

In my experience, groff has handled decades old troff source and done
a great job.  I'd not be surprised if there was something that didn't
work, but the vast majority of the stuff I've tried has worked just
fine.

--lm

Re: Unix V10 Volume 2 PDFs

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]

Hi Branden,

On Wed, Feb 12, 2025 at 07:21:07PM -0600, G. Branden Robinson wrote:
> C.  Getting a scan out there tells us at least what one software
>     configuration deemed acceptable by producers of the book generated,
>     even if it's impossible to identify details of that software
>     configuration.  That in turn helps us to judge the results of
>     _known_ software configurations--groff, and other troffs too.

Hmmm, yeah, sounds useful for a modern troff(1) implementor.  Probably
not so much for one interested in the contents of the documentation
itself.  Whenever I meet a scanned PDF while searching for a PDF, it's
not a good feeling.

> > Doesn't groff(1) handle the Unix sources?
> 
> Assuming the full source of a document is available, and no part of its
> toolchain requires software that is unavailable (like Van Wyk's "ideal"
> preprocessor) then if groff cannot satisfactorily render a document
> produced by the Bell Labs CSRC, then I'd consider that presumptively a
> bug in groff.  It's a rebuttable presumption--if one document in one
> place relied upon a _bug_ in AT&T troff to produce correct rendering, I
> think my inclination would be to annotate the problem somewhere in
> groff's documentation and leave it unresolved.
> 
> For a case where groff formats a classic Unix document "better" (in
> the sense of not unintentionally omitting a formatted equation) than
> AT&T troff, see the following.

Hmmm, yep, that's what I expected.

> https://github.com/g-branden-robinson/retypesetting-mathematics
> 
> > I expect the answer is not licenses (because I expect redistributing
> > the scanned original will be as bad as generating an apocryphal PDF in
> > terms of licensing).
> 
> I've opined before that the various aspects of Unix "IP" ownership
> appear to be so complicated and mired in the details of decades-old
> contracts in firms that have changed ownership structures multiple
> times, that legally valid answers to questions like this may not exist.
> Not until a firm that thinks it holds the rights decides it's worth the
> money to pay a bunch of archivists and copyright attorneys to go on a
> snipe hunt.
> 
> And that decision won't be made unless said firm thinks the probability
> is high that they can recover damages from infringers in excess of their
> costs.  Otherwise the decision simply sets fire to a pile of money.

Hmmmm.

> ...which isn't impossible.  Billionaires do it every day.
> 
> > I sometimes wondered if I should run the Linux man-pages build system
> > on the sources of Unix manual pages to generate an apocryphal PDF book
> > of Volume 1 of the different Unix systems.  I never ended up doing so
> > for fear of AT&T lawyers (or whoever owns the rights to their manuals
> > today), but I find it would be useful.
> 
> It's the kind of thing I've thought about doing.  :)
> 
> If you do, I very much want to know if groff appears to misbehave.

Hmmmmm, I guess I should do it.  I'll take some time, but I'll keep it
in mind for things to do this year.  For some reason, I'm more busy now
only doing free software, than when I had a regular job _and_ also did
free software.  :|


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Unix V10 Volume 2 PDFs

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

Hi,

On Thu, Feb 13, 2025 at 10:49:07AM +0100, Alejandro Colomar wrote:
> > > I sometimes wondered if I should run the Linux man-pages build system
> > > on the sources of Unix manual pages to generate an apocryphal PDF book
> > > of Volume 1 of the different Unix systems.  I never ended up doing so
> > > for fear of AT&T lawyers (or whoever owns the rights to their manuals
> > > today), but I find it would be useful.
> > 
> > It's the kind of thing I've thought about doing.  :)
> > 
> > If you do, I very much want to know if groff appears to misbehave.
> 
> Hmmmmm, I guess I should do it.  I'll take some time, but I'll keep it
> in mind for things to do this year.  For some reason, I'm more busy now
> only doing free software, than when I had a regular job _and_ also did
> free software.  :|

I tried, and found some issue: the =(1) manual page messes with my
Makefiles (portable filename character set any?).  I could build a PDF
book of Unix V10 vol1 just removing that file.  I have asked help-make@
in case anyone has an idea to workaround this.

I also have some doubts, in case anyone know the answer:

	alx@devuan:~/Downloads/unix$ tar xf v10src.tar.bz2 
	alx@devuan:~/Downloads/unix$ tree -d man/
	man/
	├── adm
	│   ├── man0
	│   ├── man1
	│   ├── man2
	│   ├── man3
	│   ├── man4
	│   ├── man5
	│   ├── man6
	│   ├── man7
	│   ├── man8
	│   ├── man9
	│   └── tjunk
	├── index
	├── man0
	│   └── tjunk
	├── man1
	├── man10
	├── man2
	├── man3
	├── man4
	├── man5
	├── man6
	├── man7
	├── man8
	├── man9
	├── mana
	├── manb
	├── manw
	└── manx

	30 directories

What's the /man/adm/ directory?  And /man/man0/tjunk/?  Should I ignore
them?


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Unix V10 Volume 2 PDFs

[наб]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Just for reference since Alex didn't link it: the PDF in question is
  https://archive.org/details/unix-v10-vol2
and the "why not" by the scanner is
  https://labyrinth.zone/notice/AqqVamq2W6Ybq8N3xY
Pull quotes:
> the troff source uses some special tools that i think only ever ran inside
> of bell labs, and i dont know what im doing wrt building them
>
> the tool that gave me hell when i briefly tried to build it is called prefer(1),
> and it’s meant as a successor to refer(1).
> it works by running a modified version of awk in a subprocess and talking over a pipe

I'm not touching that shit with a ten-mile island,
and if she, as an actual 9p user can't, I certainly can't either;
but the scanned PNGs are real and lord only knows my 7h10m are better-spent
levelling and cutting them up to produce something concrete
than apply-rock-to-head/rinse/repeating with software that barely worked,
30 years ago, in fake C, under fake unix and have naught to show for it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Unix V10 Volume 2 PDFs

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

Hi наб,

On Thu, Feb 13, 2025 at 03:12:01AM +0100, наб wrote:
> Just for reference since Alex didn't link it: the PDF in question is
>   https://archive.org/details/unix-v10-vol2
> and the "why not" by the scanner is
>   https://labyrinth.zone/notice/AqqVamq2W6Ybq8N3xY
> Pull quotes:
> > the troff source uses some special tools that i think only ever ran inside
> > of bell labs, and i dont know what im doing wrt building them
> >
> > the tool that gave me hell when i briefly tried to build it is called prefer(1),
> > and it’s meant as a successor to refer(1).
> > it works by running a modified version of awk in a subprocess and talking over a pipe
> 
> I'm not touching that shit with a ten-mile island,

I would agree on this part.  I think you misunderstood.

> and if she, as an actual 9p user can't, I certainly can't either;
> but the scanned PNGs are real and lord only knows my 7h10m are better-spent
> levelling and cutting them up to produce something concrete
> than apply-rock-to-head/rinse/repeating with software that barely worked,
> 30 years ago, in fake C, under fake unix and have naught to show for it.

I meant running groff(1) on the .roff sources of the Volume 2 papers.

Certainly, I wouldn't consider looking at the sources of AT&T troff(1)
with my eyes that already bleed when needing to read C89 code, let alone
K&R C.

Is running groff(1) on 1989 sources to re-typeset the old docs something
difficult?  I guess the main difficulty would be in putting the .roff
(or .ms, or whatever they used) sources together.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Unix V10 Volume 2 PDFs

[Norman Wilson]

For the non-TUHS folks who don't know me, I worked in
Center 1127 (the Bell Labs Computing Science Research
Center) 1984-1990, and had some hand in 9th and 10th
Edition Manuals and what passed for the V8-V10
`distributions.'

To answer Branden's points:

A.  I do know what version of troff was used to typeset
the 8th through 10th Edition manuals.  It was the version
we were using in 1127 at the time, which was indeed
Kernighan's.  The macro packages probably matter more
than the particular troff edition.

For the 10th Edition (which files I have at hand), there
was an individual mkfile (mk(1)) for each paper, so
in principle there was no fixed formatting package,
but in practice everything appears to have used troff -mpm,
with various preprocessors according the paper: prefer,
tbl, pic, ideal, and in some cases additional macros and even
odds and ends of sed and awk.

If you wanted to re-render things from scratch you'd
want all the tools.  But if you have the real troff
sources you'll have all the mkfiles--things were stored
one paper per directory.

-mpm (mpm(6) in 10/e vol 1) was a largely ms-compatible
package with special expertise in page layout.

B.  There was no such thing as a `release' after V7.
In fall 1984 we made a single V8 snapshot.  Making
that involved a lot of fiddly work, because we didn't
normally try to build systems from scratch; when we
brought in a new computer we cloned it from an existing
one.  So there was lots of fiddly work to make sure
every program in /bin and /usr/bin on the tape compiled
correctly from the source code that would be on the tape
when the cc and as and ld and libraries on the tape were
used.

We sent V8 tapes to about a dozen external places, few
of which did anything with it (many probably never even
installed it).  Which makes sense, by then we really
weren't a central source for Unix even within AT&T, let
alone to the world.  Neither did we want the support
burden that would have carried--the group's charter was
research, after all, not software support.  So the 9th
and 10th editions existed as manuals, but not as releases.
We did occasionally make one-off snapshots for other parts
of AT&T, and maybe for a university or two.  (I definitely
remember taking a snapshot to help the official AT&T System N
Unix people set up a Research system at one point, and have
a vague memory that I may have carried a tape to a university
under a special one-off license letter.)

On the other hand, troff wasn't a rapid moving target, and
unlike the stars of the modern software world, we tried not
to break things unless there was a real reason to do so.
So I suspect the troff from any system of that era would
render the Volume 2 papers properly, and am all but certain
the 10th-edition-era troff would do so even for older manuals.

C.  Just to be clear, the official 10th Edition manuals
published by Saunders College Publishing were made from
camera-ready copy prepared by us in 1127 (Doug McIlroy
did all the final work, I think) and printed on our
phototypesetter.  We didn't ship them troff source, nor
even Postscript.  We did everything including the tables
of contents and indexes and page numbering.

D.  troff is indeed not TeX, and some of us think of that
as a feature, not a bug.

I think the odds are fairly good (but not 100%) that
groff would do a reasonable job of rendering the papers;
as I said, the hard part is the macro packages.  I'm
not sure -mpm ever made it out of Research.

And there are probably copyright issues not just with
the software but with the papers themselves.  The published
manuals bear a copyright notice, after all.

Norman Wilson
Toronto ON
(A much nicer place than suburban NJ, which is why
I left the Labs when I did)

Re: [TUHS] Re: Unix V10 Volume 2 PDFs

[Dan Cross]

On Thu, Feb 13, 2025 at 8:05 AM Norman Wilson <norman@oclsc.org> wrote:
>[snip]
> -mpm (mpm(6) in 10/e vol 1) was a largely ms-compatible
> package with special expertise in page layout.
>
> [snip]
>
> I think the odds are fairly good (but not 100%) that
> groff would do a reasonable job of rendering the papers;
> as I said, the hard part is the macro packages.  I'm
> not sure -mpm ever made it out of Research.

If it's the one I'm thinking about, then it did make it out in drips
and drabs on Plan 9; it was in the 1st and 2nd Edition distributions.
However, to be used to its full effect, -mpm also required a
postprocessor, called `pm`, which was written in C++ and built with
cfront. Probably for that reason, it was not distributed with Plan 9
3rd edition or later (the later versions of Plan 9, available under an
Open Source license, did not include cfront).

All of the historical Plan 9 editions are now available under the MIT
license and available for download from the Plan 9 Foundation. I just
checked and it appears that mpm is in the tar archive for the 2nd
edition; one can download that here: https://p9f.org/dl/index.html
(It's probably in the tarball for the 1st edition too, but I didn't
look.)

Note that the source files for sys/src/cmd/pm are all named
"whatever.c", but are C++ code in disguise. At one point I took a
swing at trying to rewrite it in C, because the idea seemed cool, but
other things took precedence and I never got back to it. I haven't
tried to build it with a modern C++ compiler, but it probably wouldn't
be _that_ much work for someone motivated to do so.

        - Dan C.