[TUHS] The UNIX Command Language (1976)

[TUHS] The UNIX Command Language (1976)

[Joachim via TUHS]

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

Apologies if this has already been linked here.

"The UNIX Command Languageis the first-ever paper published on the Unix 
shell. It was written by Ken Thompson in 1976."

https://github.com/susam/tucl


Joachim

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Thomas Paulsen]

[-- Attachment #1: Type: text/html, Size: 1377 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Brantley Coile]

Thank you very much! I've been looking for where Ken used the "much needed gap" phrase.

  Brantley

> On Nov 29, 2020, at 10:10 PM, Joachim via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> Apologies if this has already been linked here.
> 
> "The UNIX Command Language is the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976."
> 
> https://github.com/susam/tucl
> 
> 
> Joachim

Re: [TUHS] The UNIX Command Language (1976)

[Tom Ivar Helbekkmo via TUHS]

Brantley Coile <brantley@coraid.com> writes:

> Thank you very much! I've been looking for where Ken used the "much
> needed gap" phrase.

That formulation is funny - but I just got into a discussion with
someone about whether ken was being intentionally funny or not.  To me,
it seems rather obvious that he chose that wording for the humourous
effect of the double-take the reader experiences.  A couple of friends
of mine, though, insist that that paragraph is just clumsily written.
Is he on record anywhere saying which it is?

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: [TUHS] The UNIX Command Language (1976)

[Clem Cole]

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

Too bad, they did not use the UNIX tool kit like troff and eqn which are
described in the paper itself, to restore it.  If you were going to the
trouble to make the 'md' file - it would have been just as easy to create
troff source.

Sigh ... get off my lawn ...

Clem

On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS <tuhs@minnie.tuhs.org>
wrote:

> Apologies if this has already been linked here.
>
> "The UNIX Command Language is the first-ever paper published on the Unix
> shell. It was written by Ken Thompson in 1976."
>
> https://github.com/susam/tucl
>
>
> Joachim
>

[-- Attachment #2: Type: text/html, Size: 2722 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Dan Cross]

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

On Mon, Nov 30, 2020 at 10:54 AM Clem Cole <clemc@ccc.com> wrote:

> Too bad, they did not use the UNIX tool kit like troff and eqn which are
> described in the paper itself, to restore it.  If you were going to the
> trouble to make the 'md' file - it would have been just as easy to create
> troff source.
>

In fairness, the Markdown renders directly from the github web UI, but I
agree that using troff/eqn would have been nice. Surely it wouldn't be that
hard to massage the markdown into troff markdown.

Sigh ... get off my lawn ...
>

I don't even have a lawn and I'm similarly distressed at the lack of homage
to the past.

        - Dan C.


On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
>> Apologies if this has already been linked here.
>>
>> "The UNIX Command Language is the first-ever paper published on the Unix
>> shell. It was written by Ken Thompson in 1976."
>>
>> https://github.com/susam/tucl
>>
>>
>> Joachim
>>
>

[-- Attachment #2: Type: text/html, Size: 3503 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Warner Losh]

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

On Mon, Nov 30, 2020 at 9:27 AM Dan Cross <crossd@gmail.com> wrote:

> On Mon, Nov 30, 2020 at 10:54 AM Clem Cole <clemc@ccc.com> wrote:
>
>> Too bad, they did not use the UNIX tool kit like troff and eqn which are
>> described in the paper itself, to restore it.  If you were going to the
>> trouble to make the 'md' file - it would have been just as easy to create
>> troff source.
>>
>
> In fairness, the Markdown renders directly from the github web UI, but I
> agree that using troff/eqn would have been nice. Surely it wouldn't be that
> hard to massage the markdown into troff markdown.
>

There are a few MD to troff converters, though I don't know how many will
convert to -ms format that was likely used historically. And given that ms
has a little more semantic info than MD does, there may be some manual
steps afterwards. Even a perfect converter would likely have manual steps
since it was also the custom back in the day to tweak this or that in the
output...

Warner

[-- Attachment #2: Type: text/html, Size: 1693 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Dan Cross]

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

On Mon, Nov 30, 2020 at 11:38 AM Warner Losh <imp@bsdimp.com> wrote:

> On Mon, Nov 30, 2020 at 9:27 AM Dan Cross <crossd@gmail.com> wrote:
>
>> On Mon, Nov 30, 2020 at 10:54 AM Clem Cole <clemc@ccc.com> wrote:
>>
>>> Too bad, they did not use the UNIX tool kit like troff and eqn which are
>>> described in the paper itself, to restore it.  If you were going to the
>>> trouble to make the 'md' file - it would have been just as easy to create
>>> troff source.
>>>
>>
>> In fairness, the Markdown renders directly from the github web UI, but I
>> agree that using troff/eqn would have been nice. Surely it wouldn't be that
>> hard to massage the markdown into troff markdown.
>>
>
> There are a few MD to troff converters, though I don't know how many will
> convert to -ms format that was likely used historically. And given that ms
> has a little more semantic info than MD does, there may be some manual
> steps afterwards. Even a perfect converter would likely have manual steps
> since it was also the custom back in the day to tweak this or that in the
> output...
>

Sure, but this is a fairly short paper...I bet one could do a fairly
faithful reproduction of the original in a couple of hours. I may take a
stab at it and send a pull request.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2227 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Larry McVoy]

So Clem, the fact that troff lost and LaTex won is a direct result of
that walled garden that was the early days of Unix.  Unless you had
a Unix license, no troff for you!  Which is a huge bummer, I'm a huge
troff fan (especially pic, but all of the preprocessors let you see the
output in your head).  I wish we lived in a troff world but we don't
and that is a direct result of haves (license holders) and have nots
(the other 99.999999% of the world).

It's not the result we would like but it is what it is.

On Mon, Nov 30, 2020 at 10:52:40AM -0500, Clem Cole wrote:
> Too bad, they did not use the UNIX tool kit like troff and eqn which are
> described in the paper itself, to restore it.  If you were going to the
> trouble to make the 'md' file - it would have been just as easy to create
> troff source.
> 
> Sigh ... get off my lawn ...
> 
> Clem
> 
> On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS <tuhs@minnie.tuhs.org>
> wrote:
> 
> > Apologies if this has already been linked here.
> >
> > "The UNIX Command Language is the first-ever paper published on the Unix
> > shell. It was written by Ken Thompson in 1976."
> >
> > https://github.com/susam/tucl
> >
> >
> > Joachim
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] The UNIX Command Language (1976)

[Clem Cole]

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

On Mon, Nov 30, 2020 at 11:37 AM Larry McVoy <lm@mcvoy.com> wrote:

> So Clem, the fact that troff lost and LaTex won is a direct result of
> that walled garden that was the early days of Unix.

Indeed




> Unless you had a Unix license, no troff for you!

yes ... but ... even UNIX binary folks had troff licenses and many/most at
ditroff licenses.  I know Masscomp just ate $5 per CPU and included it
because we did not want to mess with the older version.  If you were an
academic, it was free so most research academics had either the source or
at least a binary on their workstations.

This did not become an issue until the 386, but by that time Clark had
written what would be groff.

I think your observation is correct, but in practice, I don't think that
was what it was.

I think the academics went LaTex and that had more to do with it.   LaTex
was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead
on all them until it went walled garden when CMU sold the rights (and even
its author - Brian Ried) could not use it at a Stanford.

So your are right, Wall Garden certainly impacted the result, but I think
it was more preference in this case.



> Which is a huge bummer, I'm a huge
> troff fan (especially pic, but all of the preprocessors let you see the
> output in your head).

Ditto to both.



> I wish we lived in a troff world but we don't
>
Yep



> and that is a direct result of haves (license holders) and have nots
> (the other 99.999999% of the world).
>
Maybe -- I think the PC and Word was the real kiss of death, which I find
even more troubling.

>
> It's not the result we would like but it is what it is.
>
+1

[-- Attachment #2: Type: text/html, Size: 4454 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Theodore Y. Ts'o]

On Mon, Nov 30, 2020 at 11:54:37AM -0500, Clem Cole wrote:
> 
> I think the academics went LaTex and that had more to do with it.   LaTex
> was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead
> on all them until it went walled garden when CMU sold the rights (and even
> its author - Brian Ried) could not use it at a Stanford.

The other issue to consider is how easily could you typeset a
super-complex math expression (with integrals, sigmas, matricies,
etc., etc.) using eqn vs Scribe vs LaTeX.

For at least some of the stuff I needed to do when I was type-setting
problem set results (there was an informal competition between some of
the students regarding whose homework would get redistributed by the
TA's as the official problem set answer to the rest of the class), I
found LaTeX easier to use than Scribe, and I had access to all three
as an MIT undergraduate.  Granted, that could have been a matter of
personal preference, and I never did try to use eqn for that purpose.

	    	  	    	   - Ted

Re: [TUHS] The UNIX Command Language (1976)

[John Cowan]

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

On Mon, Nov 30, 2020 at 11:55 AM Clem Cole <clemc@ccc.com> wrote:


> I wish we lived in a troff world but we don't
>>
> Yep
>

I think O'Reilly was the last commercial publisher with a troff toolchain.
Nowadays they accept HTMLBook (their own static subset of HTML5), DocBook,
ASCIIDoc (analogous to Markdown but plain-text DocBook as opposed to
plain-text HTML), Word, and in some cases InDesign or PDF.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
And through this revolting graveyard of the universe the muffled,
maddening beating of drums, and thin, monotonous whine of blasphemous
flutes from inconceivable, unlighted chambers beyond Time; the
detestable pounding and piping whereunto dance slowly, awkwardly, and
absurdly the gigantic tenebrous ultimate gods --the blind, voiceless,
mindless gargoyles whose soul is Nyarlathotep. (Lovecraft)

[-- Attachment #2: Type: text/html, Size: 2432 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Clem Cole]

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

On Mon, Nov 30, 2020 at 1:25 PM John Cowan <cowan@ccil.org> wrote:

>
>
> On Mon, Nov 30, 2020 at 11:55 AM Clem Cole <clemc@ccc.com> wrote:
>
>
>> I wish we lived in a troff world but we don't
>>>
>> Yep
>>
>
> I think O'Reilly was the last commercial publisher with a troff toolchain.
>
I think it depends on who you are and your editor is at the said firm.  Tim
will still take troff as will John Waite at Pearson.   That said, as Jon
can tell you, Bill will not.

[-- Attachment #2: Type: text/html, Size: 1766 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[arnold]

Clem Cole <clemc@ccc.com> wrote:

> > I think O'Reilly was the last commercial publisher with a troff toolchain.

They stopped using troff directly well over 20 years ago.
These days if you're using a markup language and their toolset it's
either Asciidoc or docbook.

> I think it depends on who you are and your editor is at the said firm.  Tim
> will still take troff

I assume you mean Tim O'Reilly?  He hasn't been involved in the book
side of his business in decades, and as I said, troff isn't in the picture
there.

> as will John Waite at Pearson.

They farm such things out, they don't accept it in house.
Or the author can provide "camera ready copy", which these days
just means PDF.

>   That said, as Jon can tell you, Bill will not.

No idea who Bill is.

Arnold

Re: [TUHS] The UNIX Command Language (1976)

[Will Senn]

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

To show how current this topic is, there's an interesting and related 
discussion upcoming at NYC Bug, For the Love of Troff, on Wed @ 18:45 
(I'm guessing Eastern), via Zoom:

https://www.nycbug.org/index?action=view&id=10678



On 11/30/20 2:11 PM, arnold@skeeve.com wrote:
> Clem Cole <clemc@ccc.com> wrote:
>
>>> I think O'Reilly was the last commercial publisher with a troff toolchain.
> They stopped using troff directly well over 20 years ago.
> These days if you're using a markup language and their toolset it's
> either Asciidoc or docbook.
>
>> I think it depends on who you are and your editor is at the said firm.  Tim
>> will still take troff
> I assume you mean Tim O'Reilly?  He hasn't been involved in the book
> side of his business in decades, and as I said, troff isn't in the picture
> there.
>
>> as will John Waite at Pearson.
> They farm such things out, they don't accept it in house.
> Or the author can provide "camera ready copy", which these days
> just means PDF.
>
>>    That said, as Jon can tell you, Bill will not.
> No idea who Bill is.
>
> Arnold


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 2509 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Jon Steinhart]

arnold@skeeve.com writes:
>
> >   That said, as Jon can tell you, Bill will not.
>
> No idea who Bill is.

Bill Pollack, No Starch Press.

Re: [TUHS] The UNIX Command Language (1976)

[Nemo Nusquam]

We seem to be straying into COFF-land.  However...

On 11/30/20 13:25, John Cowan wrote:
> On Mon, Nov 30, 2020 at 11:55 AM Clem Cole <clemc@ccc.com 
> <mailto:clemc@ccc.com>> wrote:
>
>         I wish we lived in a troff world but we don't
>
>     Yep
>
>
> I think O'Reilly was the last commercial publisher with a troff 
> toolchain.  Nowadays they accept HTMLBook (their own static subset of 
> HTML5), DocBook, ASCIIDoc (analogous to Markdown but plain-text 
> DocBook as opposed to plain-text HTML), Word, and in some cases 
> InDesign or PDF.

I wonder what Tanenbaum does these days?  Prefaces of earlier versions 
of all his texts stated that they were written with troff. (And Springer 
accepts mostly LaTeX.)

N.

> John Cowan http://vrici.lojban.org/~cowan 
> <http://vrici.lojban.org/%7Ecowan> cowan@ccil.org <mailto:cowan@ccil.org>

[TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Greg A. Woods]

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

At Mon, 30 Nov 2020 11:54:37 -0500, Clem Cole <clemc@ccc.com> wrote:
Subject: Re: [TUHS] The UNIX Command Language (1976)
>
> yes ... but ... even UNIX binary folks had troff licenses and many/most at
> ditroff licenses.

I would like to try once again to dispell the apparent myth that troff
was readily available to Unix users in wider circles.

True, old troff might have been there in the distribution, but not
necessarily as many vendors didn't include it even though they had the
license since they knew most users didn't care about it, and of course
the users didn't care about troff because _nobody_ had a C/A/T, (and
hardly anyone cared to use nroff to format things for line printers).
People would install Wordstar long before they even thought about using
nroff.

Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of
the Unix sites I worked at and visited; even some time after it became
available.  Even sites running native AT&T Unix, e.g. on 3B2s, and thus
could easily obtain it, often didn't want the added expense of
installing it.

So, old troff was basically a total useless waste of disk space until
psroff came along.

Psroff made troff useful, but IF And Only IF you had a C compiler _and_
the skill to install it.  That combination was still incredibly rare.  A
C compiler was often the biggest impediment to many sites I worked at --
they didn't have programmers and they didn't want to shell out even cash
more for any programming tools (even though they had often hired me as a
consulting programmer to "fix their Unix system"!).

Then, as you said, Groff arrived, though still that required a C
compiler and (effectively for some time) a PostScript printer (while
psroff would drive the far more common laserjet and similar without
gyrations through DVI!).

In circles I travelled through if one wanted true computer typesetting
support it was _far_ easier and better (even after Groff came along) to
install TeX, even if it meant hiring a consultant to do it, since that
meant having far wider printer support (though realistically PostScript
printers were the only viable solution at some point, e.g. especially
after laser printers became available, i.e. outside Xerox and IBM shops).

> I think the academics went LaTex and that had more to do with it.   LaTex
> was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead
> on all them until it went walled garden when CMU sold the rights (and even
> its author - Brian Ried) could not use it at a Stanford.

I worked with a group of guys who were extreme fans of the PlainTeX
macros (and who absolutely hated LaTeX).  They came from academic
circles and commercial research groups.

But I agree it was those other factors that have lead to an ongoing
prevalence for TeX, and in particular its LaTeX macros; over and above
troff and anything else like either in the computer typesetting world.

I was never a fan of anything TeX (nor of anything SGML-like).

I was quite a fan of, and an extreme expert in using, troff and tbl.
However once I discovered Lout I dropped troff like a hot potato.

I continue to use Lout exclusively to this day for "fine" typesetting
work (anything that needs/prefers physical printing or a PDF).

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Larry McVoy]

On Wed, Feb 10, 2021 at 12:48:49PM -0800, Greg A. Woods wrote:
> At Mon, 30 Nov 2020 11:54:37 -0500, Clem Cole <clemc@ccc.com> wrote:
> Subject: Re: [TUHS] The UNIX Command Language (1976)
> >
> > yes ... but ... even UNIX binary folks had troff licenses and many/most at
> > ditroff licenses.
> 
> I would like to try once again to dispell the apparent myth that troff
> was readily available to Unix users in wider circles.

I had n/troff on the BSD based vaxen that UW-Madison CS had.  There was
a standard binder of docs (that I still have 35+ years later) that had
the troff, -ms, -man, -me, tbl, eqn, pic, refer docs (no grap, sadly,
I wrote my own).

The Masscomps I used had working roffs.  I've been using troff since
well before 1985 (I found that Masscomp restor.e doc, it was 1985 but
I was well into troff by then, I started with -man and -ms but was 
experimenting with -me for that paper.  I liked -me well enough but
-ms just made more sense to me so I went back to that and have been
there ever since).

The 3B1 that my roommate and I shared had working roff.

I don't remember how we got stuff printed, I was for sure using troff
for years before the postscript one came about.  

So for once, I'm gonna side with Clem on this one.  I've always had
troff and been very happy with it.  I know LaTex sort of won but I'm
not a fan.

--lm

P.S.  Groff is C++, not C.  That made it dicey until g++ got stable.

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Clem Cole]

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

ᐧ

On Wed, Feb 10, 2021 at 3:49 PM Greg A. Woods <woods@robohack.ca> wrote:

> At Mon, 30 Nov 2020 11:54:37 -0500, Clem Cole <clemc@ccc.com> wrote:
> Subject: Re: [TUHS] The UNIX Command Language (1976)
> >
> > yes ... but ... even UNIX binary folks had troff licenses and many/most
> at
> > ditroff licenses.
>
> I would like to try once again to dispell the apparent myth that troff
> was readily available to Unix users in wider circles.
>
Hard to call it a myth - it was quite available.  In fact, I never used a
single mainstream UNIX system from DEC, IBM, HP later Sun, Masscomp, Apollo
that did not have it, and many if not all small systems did also.

>
> True, old troff might have been there in the distribution, but not
> necessarily as many vendors didn't include it even though they had the
> license since they knew most users didn't care about it, and of course
> the users didn't care about troff because _nobody_ had a C/A/T,

Yes, but after Tom Ferrin created vcat(1) in the late 1970s ('77 I think,
but I've forgotten).   Many people did have access to a plotter which cost
about $1k in the late 1970s,  or even later a 'wet' laser printer like the
Imagen which cost about $5K a few years later.

(and hardly anyone cared to use nroff to format things for line printers).
>
No offense, but that's just not true. Line printers and nroff were used a
great deal to prep things, and often UNIX folks had access to a daisy shell
printer for higher quality nroff output, much less using the line printer.



> People would install Wordstar long before they even thought about using
> nroff.
>
I did not know anyone that did that.   But I'll take your word for it.
Wordstar as I recall ran on 8-bit PCs.   The only two people I knew that
had larger CP/M systems back in the day that might have supported that were
Phil Karn (*a.k.a.* KA9Q of TCP/IP for CP/M fame) and Guy Soytomayer - both
were sometimes lab partners.  But all three of us had access to the XGP in
CMU CS dept, using Scribe on the PDP-10s, but we all used nroff most of the
time because we had more cycles available on the UNIX boxes and the 10s
required going to the terminal room.   FWIW: my non-techie CMU course
professors used to let you turning papers printed off the line printer and
people used anything they had - which was Scribe on the 20s and nroff on
the Unix, boxes and I've forgotten the name of the program that ran on the
TSS, which the business majors like my roommate tended to use.


>
> Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of
> the Unix sites I worked at and visited; even some time after it became
> available.  Even sites running native AT&T Unix, e.g. on 3B2s, and thus
> could easily obtain it, often didn't want the added expense of
> installing it.
>
The only time I had a deal with pure AT&T systems was occasionally at the
AT&T, but even there most of them that I worked, had BSD or Research, based
systems.   The only 3B2 I ever saw was the one we were forced to buy by
AT&T to get a System V source license at Stellar as the reference system,
when PDP-11 and Vaxen stopped being the default.   We did get ditroff from
the toolchest for it, since we were including it in the base Stellar
system.  The Apple Laserwriter was fully in the wild with transcript by
then, so vcat was not needed.


>
> So, old troff was basically a total useless waste of disk space until
> psroff came along.
>
Sounds like you never had access to a plotter.

>
> Psroff made troff useful,

psroff was very, very late in the UNIX development.   vcat was nearly 10
years earlier, and psroff only showed up after the Apple Laserwriter which
is what - early 1985 I think.  But Versatec and the like plotter were all
over the place, much less daisy wheel printers.  True, the Hersey fonts
were not nearly as nice as PostScript and the resolution was only 200 dpi
(and it was a wet process) but most UNIX sites, particularly if you had
invested in Vaxen had them.



> but IF And Only IF you had a C compiler _and_
> the skill to install it.  That combination was still incredibly rare.

Excuse me...   most end-users sites had them.   Sun was the only one of the
majors that did not ship a C compiler with the system by default.  And as
Larry has pointed out, even that was fixed by rms fairly soon afterward.
But all of the suppliers of the majors UNIX implementations knew that you
got the C compiler with UNIX.   Jacks to open -- just include it.

It sounds like your early UNIX experiences were in a limited version, which
is a little sad and I can see that might color your thinking.



>   A C compiler was often the biggest impediment to many sites I worked at
> --
> they didn't have programmers and they didn't want to shell out even cash
> more for any programming tools (even though they had often hired me as a
> consulting programmer to "fix their Unix system"!).
>
Yeech... sorry to hear that.



> In circles I travelled through if one wanted true computer typesetting
> support it was _far_ easier and better (even after Groff came along)

Hmmm ...  you were complaining you need a C compiler for ditroff, yet groff
needs C++ IIRC.?



> to install TeX, even if it meant hiring a consultant to do it, since that
>
Which means you need a Pascal compiler BTW .... and Tex was written using
the PDP-10 Pascal extensions, so you had to have a Pascal that understood
that.  Which was often not easy, particularly on UNIX boxes.  The UCB
Pascal != PDP-10 Pascal.


> meant having far wider printer support (though realistically PostScript
> printers were the only viable solution at some point, e.g. especially
> after laser printers became available, i.e. outside Xerox and IBM shops).
>
My guess this observation is because HP was late to the Postscript world
and there while the eventual hpcat(1) was done for the vaxen and made it
the USENET, it was fairly late in time, and I'm not sure if anyone at HP or
anyone else ever wrote a ditroff backend for HP's PCL.

The key is that Apple Laserwriters were pretty cheap and since they already
did PS, most sites I knew just bought PS based ones and did not go HP until
later when PS was built-in.



> I was quite a fan of, and an extreme expert in using, troff and tbl.
>
Good to hear.


> However once I discovered Lout I dropped troff like a hot potato.
>
Never used it, but I'll take your word for it.  I believe it is very Scribe
like and looking at it you can see in the influence.
ᐧ

[-- Attachment #2: Type: text/html, Size: 12186 bytes --]

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Greg A. Woods]

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

At Wed, 10 Feb 2021 17:05:57 -0500, Clem Cole <clemc@ccc.com> wrote:
Subject: Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
>
> On Wed, Feb 10, 2021 at 3:49 PM Greg A. Woods <woods@robohack.ca> wrote:
>
> > I would like to try once again to dispell the apparent myth that troff
> > was readily available to Unix users in wider circles.
> >
> Hard to call it a myth - it was quite available.  In fact, I never used a
> single mainstream UNIX system from DEC, IBM, HP later Sun, Masscomp, Apollo
> that did not have it, and many if not all small systems did also.

I was much deeper in the trenches!  (and in Canada too)

I'm talking about small old systems, usually at very small companies but
sometimes at very small departments in larger companies.  Things like
early Motorola 68k, NCR-Tower, Convergent, Plexus, Spectrix (plus Tandy
and Altos and other Xenix-based ports).  Even with full licenses the
available nroff/troff package was often not installed as all too often
there wasn't enough spare disk space to install it.

Also with newer AT&T Unix ports, i.e. Release 2 and newer, it depended
very much on the vendor, and sometimes even the distributor, as to
whether or not the Documenter's Workbench would be a separate purchase
or not, but usually it was and most of the customers I worked with would
never pay for software that they didn't have a pressing need for, even
if it was just a few $100.

> Yes, but after Tom Ferrin created vcat(1) in the late 1970s ('77 I think,
> but I've forgotten).   Many people did have access to a plotter which cost
> about $1k in the late 1970s,  or even later a 'wet' laser printer like the
> Imagen which cost about $5K a few years later.

I don't know if	I've ever seen a Versatec plotter, though perhaps at a
trade show.

I seem to remember grad students at university getting typeset copy off
some kind of "wet" process typesetter driven by troff -- maybe even a
C/A/T, but that was so far out of reach of undergrads that it wasn't
even funny -- we just had a dot-matrix line printer (for the Unix
machine -- there were real line printers on the Multics machine).

Later on most of the kinds of customers I worked with would have a
daisy-wheel printer at best, or perhaps just a dot-matrix line printer.
That is until the HP Laserjet came along, followed of course not much
longer by the Apple LaserWriter.

> No offense, but that's just not true. Line printers and nroff were used a
> great deal to prep things, and often UNIX folks had access to a daisy shell
> printer for higher quality nroff output, much less using the line printer.

Yeah, sure, lots of us Unix fans used nroff, but I doubt I ever had any
small-system customers who used it, or would even know how to use it,
nor would they want to learn how to use it, especially if they already
had paid for a "proper" word processor....

> > People would install Wordstar long before they even thought about using
> > nroff.
> >
> I did not know anyone that did that.   But I'll take your word for it.
> Wordstar as I recall ran on 8-bit PCs.

Sorry, probably it was WordPerfect or something work-alike.

The most recent site I remember using such a word processor on Unix was
on an NCR-Tower32, which by then would have been running a newer Unix
System V, probably Release 2, though maybe I upgraded them to Release 3
or whatever was current from NCR in the day, but I don't remember the
details.  They printed to a laser, probably as PCL.  That would have
been in the very early 1990s.

> FWIW: my non-techie CMU course
> professors used to let you turning papers printed off the line printer and
> people used anything they had - which was Scribe on the 20s and nroff on
> the Unix, boxes and I've forgotten the name of the program that ran on the
> TSS, which the business majors like my roommate tended to use.

I remember learning the old "roff" on a PDP-11/60 (which was by then
running V7) and submitting course work hand-cut from 132-column fan-fold
paper.  I also remember being disappointed when they "replaced" it with
nroff (probably it had just been an old v6 binary) and I had to learn
how to format everything all over again.  :-)


> > but IF And Only IF you had a C compiler _and_
> > the skill to install it.  That combination was still incredibly rare.
>
> Excuse me...   most end-users sites had them.
>
> It sounds like your early UNIX experiences were in a limited version, which
> is a little sad and I can see that might color your thinking.

There were a great number of small sites running various different ports
of Unix -- many of which were purpose-built to run some application such
as an accounting system or word processing system.

Often the owners didn't even really know they were running Unix or some
derivative.  If the compiler was an add-on they certainly didn't have
it, even if it was a free add-on.

I think Microsoft Xenix for example always had an add-on compiler
(though perhaps some of its many sub-licensees would bundle it), and of
course by the time AT&T Unix System V came out the compiler (i.e. SGS)
and DWB were both add-ons that took up disk space and were usually added
$$$ too.

> Hmmm ...  you were complaining you need a C compiler for ditroff, yet groff
> needs C++ IIRC.?

Plain C for "psroff", but yes, indeed, C++ for groff.

> My guess this observation is because HP was late to the Postscript world
> and there while the eventual hpcat(1) was done for the vaxen and made it
> the USENET, it was fairly late in time, and

I don't think I ever heard of hpcat, and I can only find one reference
to it online with google (in an old 1985 Los Alamos newsletter).

> I'm not sure if anyone at HP or
> anyone else ever wrote a ditroff backend for HP's PCL.

Rick Richardson wrote Jetroff.  The second release became commercial
software, but I briefly used the original 1.0 "shareware" release quite
successfully:

	https://www.tuhs.org/Usenet/comp.sources.misc/1988-September/thread.html

> The key is that Apple Laserwriters were pretty cheap and since they already
> did PS, most sites I knew just bought PS based ones and did not go HP until
> later when PS was built-in.

My best ever used equipment deal (where I paid actual $$$), was for an
almost brand-new Apple LaserWriter 16/600 that had come off lease at a
PC leasing agency in Toronto.  They didn't know heads or tails about any
kind of Apple gear and didn't know how to get the Ethernet adapter for
it.  I paid just $64.00.  It was still on its first toner cartridge.  I
drove away like I'd robbed the place!  Before that I had a cranky old
monster of a PS printer of some kind -- it has a 10MB 5.25" hard drive
in it that I think contained the fonts.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[George Michaelson]

the transition from wet to dry was amazing. we had the wet, and it
worked but was fussy. I think it was some odd DPI like 120. Lowish
res. Jaggies on the fonts. I printed a poem Dave Barron wrote about
the birth of the ICL 2900 hundred in old english font, you can see the
jaggies on it. When it first comes out, it is shiny like its just been
given birth to (sorry) and some horrendous solvent I don't want to
think about evaporated, and it was done. Sort-of shiny surface. Not
very nice.

The first decent dry laser we got was a canon unit, which IIRC was in
that olivetti "we know how do do design" space-age orange shade. It
was a giant brick on its end, about the height of a bar-fridge, and it
was 200dpi I think, and we loved it. Insanely good to get things that
clean, and not have to slice a roll of paper. I mean, for the entire
time we've been talking about Xerox machines were coming down in size
although a campus printer at the bindery for PhDs is an assembly line
of giant car sized units, but even the small ones the engineers have a
black diver case of wierd tools, gizmos to reach behind the
thingamajig and tickle the whatsit with a hairy brush.. they are
seriously complex machines (or were). Getting one of these
russian-tanks in a jet-age orange italian designer bar-fridge was ..
cool.

But then.. we realised all the s/w tools we were using were designed
for US letter. Inches. Not A4 friendly. I mean, the BSD licence I've
referred to several times, It was printed on legal, it even had the
honest-to-god crimped red seal of the regents of the university of
california on it, we didn't have envelopes which fitted this stuff. We
didn't have ring binders with holes in the right places for the
printed manuals, and when we printed our own, if we didn't check and
check and check, the US-Legal / A4 thing went bananas. People hoarded
magic init sequences to make things have margins and page sizes which
worked for them. I still remember trying to co-erce 2up printing to
work nicely.

We were so desperate for decent output there was a market for a sort
of 'player piano' box which sat on an IBM golfball printer, and
hammered the keys for you. Daisy wheel was good, but you can't beat an
IBM selectric if you want to cut a roneostat for some agitprop (they
were the invention of the devil too. the ink goes everywhere)

Nowadays, a good photocopier from fuji has a 48MP camera with a giant
lens, there is none of this scanning nonsense, its one photo and done.
The smarts are in MIPS chips and do things like hide 'you leaked it'
codes in the printed output. I used one to copy my passport for a
re-issuance recently, I swear you could pass money from them (I am
told they have image recognition for money and won't print it. Damn
skynet. they're taking over already)

On Fri, Feb 12, 2021 at 7:59 AM Greg A. Woods <woods@robohack.ca> wrote:
>
> At Wed, 10 Feb 2021 17:05:57 -0500, Clem Cole <clemc@ccc.com> wrote:
> Subject: Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
> >
> > On Wed, Feb 10, 2021 at 3:49 PM Greg A. Woods <woods@robohack.ca> wrote:
> >
> > > I would like to try once again to dispell the apparent myth that troff
> > > was readily available to Unix users in wider circles.
> > >
> > Hard to call it a myth - it was quite available.  In fact, I never used a
> > single mainstream UNIX system from DEC, IBM, HP later Sun, Masscomp, Apollo
> > that did not have it, and many if not all small systems did also.
>
> I was much deeper in the trenches!  (and in Canada too)
>
> I'm talking about small old systems, usually at very small companies but
> sometimes at very small departments in larger companies.  Things like
> early Motorola 68k, NCR-Tower, Convergent, Plexus, Spectrix (plus Tandy
> and Altos and other Xenix-based ports).  Even with full licenses the
> available nroff/troff package was often not installed as all too often
> there wasn't enough spare disk space to install it.
>
> Also with newer AT&T Unix ports, i.e. Release 2 and newer, it depended
> very much on the vendor, and sometimes even the distributor, as to
> whether or not the Documenter's Workbench would be a separate purchase
> or not, but usually it was and most of the customers I worked with would
> never pay for software that they didn't have a pressing need for, even
> if it was just a few $100.
>
> > Yes, but after Tom Ferrin created vcat(1) in the late 1970s ('77 I think,
> > but I've forgotten).   Many people did have access to a plotter which cost
> > about $1k in the late 1970s,  or even later a 'wet' laser printer like the
> > Imagen which cost about $5K a few years later.
>
> I don't know if I've ever seen a Versatec plotter, though perhaps at a
> trade show.
>
> I seem to remember grad students at university getting typeset copy off
> some kind of "wet" process typesetter driven by troff -- maybe even a
> C/A/T, but that was so far out of reach of undergrads that it wasn't
> even funny -- we just had a dot-matrix line printer (for the Unix
> machine -- there were real line printers on the Multics machine).
>
> Later on most of the kinds of customers I worked with would have a
> daisy-wheel printer at best, or perhaps just a dot-matrix line printer.
> That is until the HP Laserjet came along, followed of course not much
> longer by the Apple LaserWriter.
>
> > No offense, but that's just not true. Line printers and nroff were used a
> > great deal to prep things, and often UNIX folks had access to a daisy shell
> > printer for higher quality nroff output, much less using the line printer.
>
> Yeah, sure, lots of us Unix fans used nroff, but I doubt I ever had any
> small-system customers who used it, or would even know how to use it,
> nor would they want to learn how to use it, especially if they already
> had paid for a "proper" word processor....
>
> > > People would install Wordstar long before they even thought about using
> > > nroff.
> > >
> > I did not know anyone that did that.   But I'll take your word for it.
> > Wordstar as I recall ran on 8-bit PCs.
>
> Sorry, probably it was WordPerfect or something work-alike.
>
> The most recent site I remember using such a word processor on Unix was
> on an NCR-Tower32, which by then would have been running a newer Unix
> System V, probably Release 2, though maybe I upgraded them to Release 3
> or whatever was current from NCR in the day, but I don't remember the
> details.  They printed to a laser, probably as PCL.  That would have
> been in the very early 1990s.
>
> > FWIW: my non-techie CMU course
> > professors used to let you turning papers printed off the line printer and
> > people used anything they had - which was Scribe on the 20s and nroff on
> > the Unix, boxes and I've forgotten the name of the program that ran on the
> > TSS, which the business majors like my roommate tended to use.
>
> I remember learning the old "roff" on a PDP-11/60 (which was by then
> running V7) and submitting course work hand-cut from 132-column fan-fold
> paper.  I also remember being disappointed when they "replaced" it with
> nroff (probably it had just been an old v6 binary) and I had to learn
> how to format everything all over again.  :-)
>
>
> > > but IF And Only IF you had a C compiler _and_
> > > the skill to install it.  That combination was still incredibly rare.
> >
> > Excuse me...   most end-users sites had them.
> >
> > It sounds like your early UNIX experiences were in a limited version, which
> > is a little sad and I can see that might color your thinking.
>
> There were a great number of small sites running various different ports
> of Unix -- many of which were purpose-built to run some application such
> as an accounting system or word processing system.
>
> Often the owners didn't even really know they were running Unix or some
> derivative.  If the compiler was an add-on they certainly didn't have
> it, even if it was a free add-on.
>
> I think Microsoft Xenix for example always had an add-on compiler
> (though perhaps some of its many sub-licensees would bundle it), and of
> course by the time AT&T Unix System V came out the compiler (i.e. SGS)
> and DWB were both add-ons that took up disk space and were usually added
> $$$ too.
>
> > Hmmm ...  you were complaining you need a C compiler for ditroff, yet groff
> > needs C++ IIRC.?
>
> Plain C for "psroff", but yes, indeed, C++ for groff.
>
> > My guess this observation is because HP was late to the Postscript world
> > and there while the eventual hpcat(1) was done for the vaxen and made it
> > the USENET, it was fairly late in time, and
>
> I don't think I ever heard of hpcat, and I can only find one reference
> to it online with google (in an old 1985 Los Alamos newsletter).
>
> > I'm not sure if anyone at HP or
> > anyone else ever wrote a ditroff backend for HP's PCL.
>
> Rick Richardson wrote Jetroff.  The second release became commercial
> software, but I briefly used the original 1.0 "shareware" release quite
> successfully:
>
>         https://www.tuhs.org/Usenet/comp.sources.misc/1988-September/thread.html
>
> > The key is that Apple Laserwriters were pretty cheap and since they already
> > did PS, most sites I knew just bought PS based ones and did not go HP until
> > later when PS was built-in.
>
> My best ever used equipment deal (where I paid actual $$$), was for an
> almost brand-new Apple LaserWriter 16/600 that had come off lease at a
> PC leasing agency in Toronto.  They didn't know heads or tails about any
> kind of Apple gear and didn't know how to get the Ethernet adapter for
> it.  I paid just $64.00.  It was still on its first toner cartridge.  I
> drove away like I'd robbed the place!  Before that I had a cranky old
> monster of a PS printer of some kind -- it has a 10MB 5.25" hard drive
> in it that I think contained the fonts.
>
> --
>                                         Greg A. Woods <gwoods@acm.org>
>
> Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Dave Horsfall]

On Thu, 11 Feb 2021, Greg A. Woods wrote:

> I don't know if I've ever seen a Versatec plotter, though perhaps at a 
> trade show.

The LV-11?  We had one at Uni of NSW; it spent most of its time printing 
biorhythm charts which were all the rage back then.

-- Dave

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Ron Natalie]

I hated those things.   They were what we used for regular listings at 
BRL and the chemicals made my skin break out.  The chemicals also 
reacted with the ink in the standard government issue felt tip pens 
(which ironically were made by blind people) and caused your notes to 
fade quickly (and the pens to stop working).


------ Original Message ------
From: "Dave Horsfall" <dave@horsfall.org>
To: "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Sent: 2/12/2021 5:13:22 PM
Subject: Re: [TUHS] troff was not so widely usable (was: The UNIX 
Command Language (1976))

>On Thu, 11 Feb 2021, Greg A. Woods wrote:
>
>>I don't know if I've ever seen a Versatec plotter, though perhaps at a trade show.
>
>The LV-11?  We had one at Uni of NSW; it spent most of its time printing biorhythm charts which were all the rage back then.
>
>-- Dave

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Jon Steinhart]

Greg A. Woods writes:
>
> Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of
> the Unix sites I worked at and visited; even some time after it became
> available.  Even sites running native AT&T Unix, e.g. on 3B2s, and thus
> could easily obtain it, often didn't want the added expense of
> installing it.

Maybe for you; I had it everywhere that I worked.

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[George Michaelson]

I wonder if this was a university BSD/Bell licence vs "everyone else"
thing. I know we had ubiquitous use of nroff, troff and ditroff, in
succession at Leeds and York across 82-84 and onward. That was with a
benson-varian wet process printer from roll paper, cut marks thrown in
free.

because I'd used Tops-10 Runoff at uni, nroff made sense. The guys who
walked in other doors wound up tooled in TeX which I didn't {relax}
get.

On Thu, Feb 11, 2021 at 8:37 AM Jon Steinhart <jon@fourwinds.com> wrote:
>
> Greg A. Woods writes:
> >
> > Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of
> > the Unix sites I worked at and visited; even some time after it became
> > available.  Even sites running native AT&T Unix, e.g. on 3B2s, and thus
> > could easily obtain it, often didn't want the added expense of
> > installing it.
>
> Maybe for you; I had it everywhere that I worked.

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Ron Natalie]

We used nroff quite a bit with both the Model37 teletype (for which it 
wsa designed, ours even had the greek box on it) and with output filters 
for the lineprinter and the Diablos.

Later on we drove troff into cat emulators that used Versatec printers.  
    I don’t knwo wher Berkely’s vcat got their fonts, but the JHU verset 
had an amusing history on that.

George Toth went down to the NRL which had a real CAT and printed out 
the fonts in large point size on film.    In the basement of the 
biophysics bulding was a scanning transmission electron microscope which 
used a PDP-11/20 as its controller and an older (512x512 or so) 
framebuffer.    George took the scanning wires off the microsope nad 
hooked them up to the X and Y of a tektronics oscilliscope.    Then he 
put a photomutlipler tube in a scope camera housing and hoked the sense 
wire from the microscope to that.

He now had the worlds most expensive flying spot scanner.   He’d tape 
one letter at a time to the scope and then bring up the microscope 
sofware (DOS/BATCH I think) and tell it to run the microscope.    Then 
without powering down the memory in the framebuffer, he’d boot up 
miniunix and copy the stuff from the framebuffer to an RX05 pack.
After months of laboriously scanning he was able to write the CAT 
emulator.

I had gone to work for Martin Marietta wirking on a classified project 
so I wrote hacks to the -mm macro package to handle security markings 
(automatically putting the highest on each page on thte top and bottom). 
    Later when ditroff became available I continued to use it with 
various laserprinters.    I even wrote macropackages to emulate IBM’s 
doc style when we were contracting with them.

This was all to the chagrin of my boss who wanted us to switch to 
Framemaker.

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Larry McVoy]

On Thu, Feb 11, 2021 at 12:27:17AM +0000, Ron Natalie wrote:
> George Toth went down to the NRL which had a real CAT and printed out the
> fonts in large point size on film.    In the basement of the biophysics
> bulding was a scanning transmission electron microscope which used a
> PDP-11/20 as its controller and an older (512x512 or so) framebuffer.
> George took the scanning wires off the microsope nad hooked them up to the X
> and Y of a tektronics oscilliscope.    Then he put a photomutlipler tube in
> a scope camera housing and hoked the sense wire from the microscope to that.
> 
> He now had the worlds most expensive flying spot scanner.   He???d tape one
> letter at a time to the scope and then bring up the microscope sofware
> (DOS/BATCH I think) and tell it to run the microscope.    Then without
> powering down the memory in the framebuffer, he???d boot up miniunix and
> copy the stuff from the framebuffer to an RX05 pack.
> After months of laboriously scanning he was able to write the CAT emulator.

That's dedication, what else did George do?

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Clem Cole]

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

Ron. That’s awesome.  Ferrin used the Same set of Hersey Font that the XGP
used.  He got them from Stanford as I recall but they were publically (aka
open source)

On Wed, Feb 10, 2021 at 7:28 PM Ron Natalie <ron@ronnatalie.com> wrote:

> We used nroff quite a bit with both the Model37 teletype (for which it
> wsa designed, ours even had the greek box on it) and with output filters
> for the lineprinter and the Diablos.
>
> Later on we drove troff into cat emulators that used Versatec printers.
>     I don’t knwo wher Berkely’s vcat got their fonts, but the JHU verset
> had an amusing history on that.
>
> George Toth went down to the NRL which had a real CAT and printed out
> the fonts in large point size on film.    In the basement of the
> biophysics bulding was a scanning transmission electron microscope which
> used a PDP-11/20 as its controller and an older (512x512 or so)
> framebuffer.    George took the scanning wires off the microsope nad
> hooked them up to the X and Y of a tektronics oscilliscope.    Then he
> put a photomutlipler tube in a scope camera housing and hoked the sense
> wire from the microscope to that.
>
> He now had the worlds most expensive flying spot scanner.   He’d tape
> one letter at a time to the scope and then bring up the microscope
> sofware (DOS/BATCH I think) and tell it to run the microscope.    Then
> without powering down the memory in the framebuffer, he’d boot up
> miniunix and copy the stuff from the framebuffer to an RX05 pack.
> After months of laboriously scanning he was able to write the CAT
> emulator.
>
> I had gone to work for Martin Marietta wirking on a classified project
> so I wrote hacks to the -mm macro package to handle security markings
> (automatically putting the highest on each page on thte top and bottom).
>     Later when ditroff became available I continued to use it with
> various laserprinters.    I even wrote macropackages to emulate IBM’s
> doc style when we were contracting with them.
>
> This was all to the chagrin of my boss who wanted us to switch to
> Framemaker.
>
>
>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 2658 bytes --]

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Richard Salz]

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

There used to be a great memo all about stealing fonts.  Joel might
remember it, as it circulated among CMU MIT Stanford etc. in the days of
the XGP and Dover printers.

[-- Attachment #2: Type: text/html, Size: 218 bytes --]

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[George Michaelson]

As long as you do it in the USA, it isn't stealing. I was going to
write about what a fantastic steal this was but recalled a quirk in US
IPR around fonts, and their images.

On Thu, Feb 11, 2021 at 12:00 PM Richard Salz <rich.salz@gmail.com> wrote:
>
> There used to be a great memo all about stealing fonts.  Joel might remember it, as it circulated among CMU MIT Stanford etc. in the days of the XGP and Dover printers.
>

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Richard Salz]

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

On Wed, Feb 10, 2021, 9:04 PM George Michaelson <ggm@algebras.org> wrote:

> As long as you do it in the USA, it isn't stealing.
>

Not sure of that, but there are other techniques to protect it, like
patent, trademark, and trade secret.  Just like unpublished proprietary
source code of AT&T, to coin a phrase.

>

[-- Attachment #2: Type: text/html, Size: 811 bytes --]

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Steve Nickolas]

On Wed, 10 Feb 2021, Richard Salz wrote:

> On Wed, Feb 10, 2021, 9:04 PM George Michaelson <ggm@algebras.org> wrote:
>
> Not sure of that, but there are other techniques to protect it, like
> patent, trademark, and trade secret.  Just like unpublished proprietary
> source code of AT&T, to coin a phrase.

I think you can't copyright the shapes, but you can copyright the vectors 
that generate them because they're technically code.

Something weird like that.

But that's how you can have all those knockoff fonts Bitstream did, and 
why a font like Book Antiqua was possible under US law.

-uso.

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Toby Thain]

On 2021-02-10 10:02 p.m., Steve Nickolas wrote:
> On Wed, 10 Feb 2021, Richard Salz wrote:
> 
>> On Wed, Feb 10, 2021, 9:04 PM George Michaelson <ggm@algebras.org> wrote:
>>
>> Not sure of that, but there are other techniques to protect it, like
>> patent, trademark, and trade secret.  Just like unpublished proprietary
>> source code of AT&T, to coin a phrase.
> 
> I think you can't copyright the shapes, but you can copyright the
> vectors that generate them because they're technically code.
> 
> Something weird like that.
> 
> But that's how you can have all those knockoff fonts Bitstream did, and
> why a font like Book Antiqua was possible under US law.

Added irony and lesson: Bitstream's digitisations and originals were
markedly better and more complete than Adobe's, who were able to use the
licensed names.

--T

> 
> -uso.

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[Ron Natalie]

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

It's important to know the difference between a font and a typeface.    
A typeface isn't protectable.  That's the representation of the actual 
letters on the printed page (or screen in our case).     George was free 
to scan the output of the phototypesetter.

The font is the process to make these (in modern days small programs 
that generate the letters).  This is what can be protected by copyright.

The name can be protected by trademark as well.    HELVETICA is a 
trademark (now) of Mergenthaler Linotype.    Arial is a similar typeface 
but that name is owned by Monotype.

Straying a little from the topic, a real Linotype machine is a joy to 
behold.   They have one at the Baltimore Museum of Science and Industry 
that they still fire up weekly.   What it does is integrate a keyboard 
with the actual fonts (molds for molten lead) and casts a line of type 
(hence the name) at a time.   After it does so, the molds go back into 
sorted hoppers for further use.

To answer the other question about George Toth at JHU.   He was our 
documetnation guy and went off to work for Airinc or something.  I've 
not heard from him in a long time.    We continued to use his verset and 
a versatec for a while with straight troff.   I also hacked it to draw 
on the framebuffers in BRL's graphics labs.    Later more fonts became 
available from the Berkeley vcat/vtroff.   Ditroff allowed direct 
selection of mutliple fonts as opposed to having to hack on the 
"railmag" file (remember that guys?).

Standard troff voodoo, just put a power of two backslashes in front of 
it until it works and if you still have problems add a \c.

-Ron

[-- Attachment #2: Type: text/html, Size: 2932 bytes --]

Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))

[John Cowan]

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

On Thu, Feb 11, 2021 at 11:56 AM Ron Natalie <ron@ronnatalie.com> wrote:


> It's important to know the difference between a font and a typeface.    A
> typeface isn't protectable.  That's the representation of the actual
> letters on the printed page (or screen in our case).     George was free to
> scan the output of the phototypesetter.
>

Or to make use of bitmap fonts, which are exact representations of the
typeface, at least in the U.S.  (In Europe there are design patents that
make typefaces protectable.)  See section 1.12 of <
http://www.faqs.org/faqs/fonts-faq/part2/> for the relevant quotations from
the Code of Federal Regulations.

Some time ago, I was hacking on the program FIGlet, which is a
bells-and-whistles banner program: you write FIGfonts as plain text files
with N lines per big character, where N is the font height measured in
small characters.  It is capable of kerning big characters nicely by using
a chosen small character to represent a "squishable space".

My main two improvements were to extend the font format to represent up to
2^31 big characters and to accept mapping tables to convert input from a
specific encoding to font indices.  (I ended up writing a comprehensive
decoder for arbitrary ISO 2022 text, possibly the only one that has ever
existed.)

In addition, I wrote a program to convert X BDS (bitmap) fonts to FIGfonts,
and packaged the standard BDS fonts with the standard FIGlet library.  That
served me well later when I was working for the Associated Press.  My boss
told me that the New York Daily News, which was downstairs in the same
building, was tired of paying Reuters for a program running on a PC that
fetched the current headlines from Reuters and displayed them on a huge
news ticker mounted on several sides of the newsroom, which was the size of
a NY city block.  Because the AP is a not-for-profit collective, once you
buy in, all the services are free.

The Reuters program was a Windows binary, and the manual they had for the
ticker turned out to be for a different model altogether.  I called the
manufacturer and got the correct manual (it took several days).  I wrote a
program in Perl that would fetch an AP headline feed (in RSS) which I was
responsible for, load up the X FIGfont specified as a command-line
argument, and send the text to the ticker, a matter of writing a single
column of bits and then the next and then the next, as the hardware took
care of the actual horizontal scrolling for me.

Once I had it running, I walked around to various people in the newsroom
who didn't look too busy, and asked them what they thought?  The general
response was a weak "LGTM", until I got to one guy who said, "No, it
doesn't look quite right."

"If you'll follow me," I said, "I'll see what I can do."  He and the guy in
the next cube followed me to the desk where the PC sat.  I killed the
program and started it up with the name of a different font.  "Mmm, not
quite."

We went through a number of fonts until I got "Yes!  Now _that_ looks like
a real newsroom font!"  He asked the other guy, "Do you agree?"

"Yes, that's great!"

So they were happy and I was happy and when I got back to AP my boss was
happy.  Only later did I find out that my two guys were the city editor and
the managing editor of the Daily News!

Standard troff voodoo, just put a power of two backslashes in front of it
> until it works and if you still have problems add a \c.
>

See "The Telnet Song" at <https://www.glaver.org/ftp/humor/telnet-song.txt>.

[-- Attachment #2: Type: text/html, Size: 6684 bytes --]

Re: [TUHS] troff was not so widely usable

[Mary Ann Horton]

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

We had vtroff at Berkeley around 1980, on the big Versatec wet plotter, 
4 pages wide. We got really good at cutting up the pages on the output.

It used the Hershey font. It was horrible. Mangled somehow, lots of 
parts of glyphs missing. I called it the "Horse Shit" font.

I took it as my mission to clean it up. I wrote "fed" to edit it, dot by 
dot, on the graphical HP 2648 terminal at Berkeley. I got all the fonts 
reasonably cleaned up, but it was laborious.

I still hated Hershey. It was my dream to get real C/A/T output at the 
largest 36 point size, and scan it in to create a decent set of Times 
fonts. I finally got the C/A/T output years later at Bell Labs, but 
there were no scanners available to me at the time. Then True Type came 
along and it was moot.

I did stumble onto one nice rendition of Times Roman in one point size, 
from Stanford, I think. I used it to write banner(6).

On 2/10/21 5:53 PM, Clem Cole wrote:
> Ron. That’s awesome.  Ferrin used the Same set of Hersey Font that the 
> XGP used.  He got them from Stanford as I recall but they were 
> publically (aka open source)
>
> On Wed, Feb 10, 2021 at 7:28 PM Ron Natalie <ron@ronnatalie.com 
> <mailto:ron@ronnatalie.com>> wrote:
>
>     We used nroff quite a bit with both the Model37 teletype (for
>     which it
>     wsa designed, ours even had the greek box on it) and with output
>     filters
>     for the lineprinter and the Diablos.
>
>     Later on we drove troff into cat emulators that used Versatec
>     printers.
>         I don’t knwo wher Berkely’s vcat got their fonts, but the JHU
>     verset
>     had an amusing history on that.
>
>     George Toth went down to the NRL which had a real CAT and printed out
>     the fonts in large point size on film.    In the basement of the
>     biophysics bulding was a scanning transmission electron microscope
>     which
>     used a PDP-11/20 as its controller and an older (512x512 or so)
>     framebuffer.    George took the scanning wires off the microsope nad
>     hooked them up to the X and Y of a tektronics oscilliscope.   Then he
>     put a photomutlipler tube in a scope camera housing and hoked the
>     sense
>     wire from the microscope to that.
>
>     He now had the worlds most expensive flying spot scanner.  He’d tape
>     one letter at a time to the scope and then bring up the microscope
>     sofware (DOS/BATCH I think) and tell it to run the microscope.   
>     Then
>     without powering down the memory in the framebuffer, he’d boot up
>     miniunix and copy the stuff from the framebuffer to an RX05 pack.
>     After months of laboriously scanning he was able to write the CAT
>     emulator.
>
>     I had gone to work for Martin Marietta wirking on a classified
>     project
>     so I wrote hacks to the -mm macro package to handle security markings
>     (automatically putting the highest on each page on thte top and
>     bottom).
>         Later when ditroff became available I continued to use it with
>     various laserprinters.    I even wrote macropackages to emulate IBM’s
>     doc style when we were contracting with them.
>
>     This was all to the chagrin of my boss who wanted us to switch to
>     Framemaker.
>
>
>
> -- 
> Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 4962 bytes --]

Re: [TUHS] troff was not so widely usable

[Larry McVoy]

The Hershey fonts were what we had, they kinda sucked but you worked 
with them.  I think is a passage, you know those fonts, you were there,
it was not great.  People who haven't been there have no idea how lucky
they are.

On Wed, Feb 10, 2021 at 06:30:31PM -0800, Mary Ann Horton wrote:
> We had vtroff at Berkeley around 1980, on the big Versatec wet plotter, 4
> pages wide. We got really good at cutting up the pages on the output.
> 
> It used the Hershey font. It was horrible. Mangled somehow, lots of parts of
> glyphs missing. I called it the "Horse Shit" font.
> 
> I took it as my mission to clean it up. I wrote "fed" to edit it, dot by
> dot, on the graphical HP 2648 terminal at Berkeley. I got all the fonts
> reasonably cleaned up, but it was laborious.
> 
> I still hated Hershey. It was my dream to get real C/A/T output at the
> largest 36 point size, and scan it in to create a decent set of Times fonts.
> I finally got the C/A/T output years later at Bell Labs, but there were no
> scanners available to me at the time. Then True Type came along and it was
> moot.
> 
> I did stumble onto one nice rendition of Times Roman in one point size, from
> Stanford, I think. I used it to write banner(6).
> 
> On 2/10/21 5:53 PM, Clem Cole wrote:
> >Ron. That???s awesome.?? Ferrin used the Same set of Hersey Font that the
> >XGP used.?? He got them from Stanford as I recall but they were publically
> >(aka open source)
> >
> >On Wed, Feb 10, 2021 at 7:28 PM Ron Natalie <ron@ronnatalie.com
> ><mailto:ron@ronnatalie.com>> wrote:
> >
> >    We used nroff quite a bit with both the Model37 teletype (for
> >    which it
> >    wsa designed, ours even had the greek box on it) and with output
> >    filters
> >    for the lineprinter and the Diablos.
> >
> >    Later on we drove troff into cat emulators that used Versatec
> >    printers.
> >    ?? ?? I don???t knwo wher Berkely???s vcat got their fonts, but the JHU
> >    verset
> >    had an amusing history on that.
> >
> >    George Toth went down to the NRL which had a real CAT and printed out
> >    the fonts in large point size on film.?? ?? In the basement of the
> >    biophysics bulding was a scanning transmission electron microscope
> >    which
> >    used a PDP-11/20 as its controller and an older (512x512 or so)
> >    framebuffer.?? ?? George took the scanning wires off the microsope nad
> >    hooked them up to the X and Y of a tektronics oscilliscope. ?? Then he
> >    put a photomutlipler tube in a scope camera housing and hoked the
> >    sense
> >    wire from the microscope to that.
> >
> >    He now had the worlds most expensive flying spot scanner. ??He???d tape
> >    one letter at a time to the scope and then bring up the microscope
> >    sofware (DOS/BATCH I think) and tell it to run the microscope.?? ??
> >    Then
> >    without powering down the memory in the framebuffer, he???d boot up
> >    miniunix and copy the stuff from the framebuffer to an RX05 pack.
> >    After months of laboriously scanning he was able to write the CAT
> >    emulator.
> >
> >    I had gone to work for Martin Marietta wirking on a classified
> >    project
> >    so I wrote hacks to the -mm macro package to handle security markings
> >    (automatically putting the highest on each page on thte top and
> >    bottom).
> >    ?? ?? Later when ditroff became available I continued to use it with
> >    various laserprinters.?? ?? I even wrote macropackages to emulate IBM???s
> >    doc style when we were contracting with them.
> >
> >    This was all to the chagrin of my boss who wanted us to switch to
> >    Framemaker.
> >
> >
> >
> >-- 
> >Sent from a handheld expect more typos than usual

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] troff was not so widely usable

[Andrew Hume]

there was actually a weird fuss about the Merganthaler typesetter.

Ken figured out how the fonts were encoded and so we had the raw outline data for
all the fonts (they were gorgeous!). this enabled us to add in special characters like
the peter weinberger face.

ken wanted to do the right thing and tried to license the fonts from Merganthaler,
but we had endless discussions where Ken would say “we know how the fonts are encoded,
can we license them?” and the sales person would say “no you can’t; they’re secret”,
and so on. we’d even show them the peter face but to no avail. so we kinda flew
under the radar for that (but we tried!).

the typesetter itself was entertaining; if i recall correctly, the software ran on a 8in floppy
and Ken wrote a B compiler/run time system for the computer inside.

andrew

Re: [TUHS] troff was not so widely usable

[Rob Pike]

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

https://www.cs.princeton.edu/~bwk/202/index.html

On Thu, Feb 11, 2021 at 6:05 PM Andrew Hume <andrew@humeweb.com> wrote:

> there was actually a weird fuss about the Merganthaler typesetter.
>
> Ken figured out how the fonts were encoded and so we had the raw outline
> data for
> all the fonts (they were gorgeous!). this enabled us to add in special
> characters like
> the peter weinberger face.
>
> ken wanted to do the right thing and tried to license the fonts from
> Merganthaler,
> but we had endless discussions where Ken would say “we know how the fonts
> are encoded,
> can we license them?” and the sales person would say “no you can’t;
> they’re secret”,
> and so on. we’d even show them the peter face but to no avail. so we kinda
> flew
> under the radar for that (but we tried!).
>
> the typesetter itself was entertaining; if i recall correctly, the
> software ran on a 8in floppy
> and Ken wrote a B compiler/run time system for the computer inside.
>
> andrew

[-- Attachment #2: Type: text/html, Size: 1371 bytes --]

Re: [TUHS] troff was not so widely usable

[John Gilmore]

Andrew Hume <andrew@humeweb.com> wrote:
> ken wanted to do the right thing and tried to license the fonts from
> Merganthaler, but we had endless discussions where Ken would say "we
> know how the fonts are encoded, can we license them?" and the sales
> person would say "no you can't; they're secret"...

The 202 reconstruction paper also bemoans the bit-rot loss of the
information about the Mergenthaler character representation.

This reminded me of a project that I and a small team did in the 1980s.
We were licensees of Sun's NeWS source code, and we wanted our software
to be able to use the wide variety of fonts sold commercially by Adobe
and font design companies.  The problem was, they were encoded in Adobe
Type 1 font definitions, which Adobe considered a proprietary trade
secret.  Due to the lack of copyright protection for fonts (whose whole
raison d'etre is to be copied onto paper many thousands or millions of
times by each user), font designers used security by obscurity to
protect their work.

Our team ended up pulling the ROMs out of an original LaserWriter, and
writing and improving a 68000 disassembler.  One of our team members
read the code, figured out which parts handled these fonts, and how it
decoded them.  He wrote that down in his own words in a plain text
document, not a program, following the prevailing court decisions about
how to avoid copyright issues while reverse-engineering a trade secret.
Ultimately, we released that document to some interested people, so that
others could implement support for Type 1 fonts.  Shortly afterward,
Adobe magnanimously decided to "release the specification", as Wikipedia
says.  Later, I got a nice note from L. Peter Deutsch, maintainer of
Ghostscript, who said:

  I just received my copy of the Adobe Type 1 Font Format book, and
  compared the contents against the message you sent me last July.  You
  guys at Grasshopper really did a good job of cracking the format.  I
  was amused to see that the book omits quite a few operators that you
  deciphered on your own.

This wasn't too long after Adobe had also been threatening Sun and its
NeWS licensees for re-implementing PostScript from its spec, rather than
licensing it from them.  I had noticed a paragraph in the prospectus for
their IPO, which said something like, "Adobe has put PostScript into the
public domain in order to encourage its wide use."  Either the language
was free for anyone to implement, or they were guilty of securities
fraud.  When hoist on that petard, so to speak, they backed down.

	John
	
Appendix:  The reverse-engineered font format.  I was happy to be able
to find a copy of this on my current machine -- it too could have
bit-rotted in the last 30 years.  File mod date is 1989.  I am not
the author.

		Description of Adobe PostScript FontType 1

PostScript FontType 1 is Adobe's proprietary font format.  The
internal fonts in Apple LaserWriters (the Times, Helvetica, and
Courier families) are stored in this format, although the stroke
descriptions are not normally available outside the LaserWriter.
Other fonts from Adobe are also in this format, although an additional
layer of encryption prevents the stroke descriptions from being
directly visible.

IMPORTANT NOTE: The shrink-wrap license agreement under which external
Adobe fonts are distributed expressly forbids the decryption and
decompilation of these fonts.  It does not appear to forbid the using
of a program to decrypt and display these fonts, (since this is what
happens to them inside a PostScript printer) as long as they are not
used on more than one PRINTER at a time.

PostScript fonts are accessed through Font Dictionaries.  See the Red
Book, section 5.3, for a description of the standard entries in a Font
Dictionary.  The entries we will concern ourselves with here are the
dictionaries CharStrings and Private.  The character shape
descriptions are stored in CharStrings in an encrypted format.  The
shape descriptions are reached via the Encoding vector, see section
5.4.  When a character needs to be rendered, a pseudo-code interpreter
is called, and handed the encrypted shape description, and the Font
Dictionary.

The pseudo-code interpreter checks that this is a valid Type 1 font.
The Font Dictionary for a valid font must contain an entry called
`Private', which is a dictionary.  Private must contain the entry
`password', an integer having the value 5839.

The shape descriptions have the ability to call other encrypted
routines, accessed by their index in the array `Subrs', defined in
Private.  The encrypted routines can also call PostScript code
directly, executing an element from the array `OtherSubrs', defined in
Private.

Execution of the pseudo-code occurs in the same environment as the
BuildChar routine for a user defined font (see section 5.7).  A gsave
precedes this execution, and the CTM is modified by the FontMatrix.
Upon exiting, a grestore is performed, and the currentpoint is updated
by the width of the character.

Encrypted routines from CharStrings and Subrs can be decrypted with
the following program.  Routines in OtherSubrs are ordinary,
unencrypted PostScript code.

#include <stdio.h>

int magic1, magic2, magic3, magic4, mask;

main()
{
	int c, d, skip4;

#ifdef eexec
	magic1 = 0x9a36dda2 ;
	magic2 = 0x9a3704d3 ;
#else
	magic1 = 0x3f8927b5 ;
	magic2 = 0x3fea375f ;
#endif
	magic3 = 0x3fc5ce6d ;
	magic4 = 0x0d8658bf ;

	mask = magic1 ^ magic2 ;
	skip4 = 0 ;

	printf("<");
	while ((c=getchar())!=EOF) {
		d = ((mask >> 8) ^ c) & 0xff ;
		if (++skip4 > 4)
#ifdef eexec
			putchar(d);
#else
			printf(" %02x", d);
#endif
		mask = magic4 + magic3 * (mask + c) ;
		}
	printf(" >");
	exit(0);
}

Note that this is the same decryption algorythm used for eexec, except
that the initial mask value, as determined by magic1 and magic2, is
different.  The result of decrypting is a font rendering pseudo code.
Strings are stored encrypted in memory, and decrypted on the fly by
the interpreter as it executes the pseudo-code.

		Description of the pseudo-code.

The pseudo-code interpreter obtains bytes in sequence from the
decryption routine.  These bytes are grouped into a sequence of
instructions.  Each instruction encodes either a number (which is
pushed onto an internal stack), or an operation (which is performed).
The initial byte of each pseudo-code instruction encodes its type and
length.

Initial bytes in the range 0x00-0x1f (inclusive) encode operations.
Common operations are encoded completely by a single byte, and require
no additional bytes.  Less common operations are encoded in two bytes.
The initial byte of a two byte operation is always 0x0c.  The second
byte has a value in the range 0x00-0x21 (inclusive), which specifies
the operation.

Initial bytes in the range 0x20-0xf6 (inclusive) encode small numbers.
No additional bytes are required for a small number.  The value pushed
on the stack is the initial byte minus 0x8b.

Initial bytes in the range 0xf7-0xfe (inclusive) encode medium
numbers.  Medium numbers are followed by one additional byte.  Medium
numbers come in two flavors: positive, and negative.  Initial bytes in
the range 0xf7-0xfa (inclusive) encode positive numbers, the remainder
are negative.  The magnitude of the number pushed is:

	(( ((initial_byte-0xf7)&3) << 8) | additional_byte) + 0x6c

If the initial byte indicates that the number is negative, the number
calculated above is negated before being pushed onto the stack.

An initial byte of 0xff indicates a large number.  A large number
requires 4 additional bytes to specify its value.  The large number's
value is encoded directly in the additional bytes, most significant
byte first, in decending order of significance.

When a number is encountered, it is pushed onto an internal stack
(seperate from the PostScript operand stack).  Most operations take
values from this stack, and a few return values on the stack.  In
general it is not important that this is not the real operand stack.
The exceptions are OtherSubrs and StackShift.  One of the arguments to
OtherSubrs is an argument count.  It transfers that many arguments
from the internal stack to the operand stack before calling the
PostScript procedure.  After the procedure returns, StackShift may be
used to transfer individual values from the operand stack to the
internal stack.

Another difference between the stacks is that some of the operations
clear the stack after execution.  These operations read their
arguments from the bottom of the stack, not the top, so in this sence,
it isn't really a stack, but it can still be thought of as behaving
like one, at least locally.  Operations which exhibit this behavior
are marked below with an *.

Many of the operations perform functions similar to certain PostScript
operators.  In these cases, only the name of the appropriate
PostScript operator is given.  Many of the path extension commands
have additional versions which restrict the motion associated with
them to being horizontal or vertical, thus one fewer argument is
needed for them.  These are identified by an `h' or `v', generally as
the second character of the name.  Thus rhlineto is equivalent to:

	{ 0 exch rlineto }

Additionally, the operators max and min are available, which are, for
some reason, missing from PostScript.

Codes labeled `(variable)' look up the given name in the Private
dictionary and push the associated value onto the internal stack.


		Descriptions of short operations.

0x00 *	VHintWidth	ycenter ==> -
0x01 *	VHint		bottom vwidth ==> -
0x02 *	HHintWidth	xcenter ==> -
0x03 *	HHint		left hwidth ==> -
	These operations give information about the position of some
of the features of a character to the non-linear scaling code.  The
dynamics of the non-linear scaling is not yet clear.  The *Width
operations take one argument, assuming StrokeWidth as the second arg
(the first arg indicates the center of the line to be stroked).  The
other operations take 2 arguments, the first being a (horizontal or
vertical) position of the (left or bottom) side of the feature, and
the second being the width of the feature being described.  These, and
similar hint routines, are called before any path construction
operators.

0x04 *	rvmoveto	ydelta ==> -
0x05 *	rlineto		xdelta ydelta ==> -
0x06 *	rhlineto	xdelta ==> -
0x07 *	rvlineto	ydelta ==> -

0x08 *	rspline		dx1 dy1 dx2 dy2 dx3 dy3 ==> -
	similar to rcurveto, but each control point is specified
relative to the previous one, instead of relative to the currentpoint. 

0x09 *	closepath	- ==> -

0x0a	Subrs		sub ==> -
	takes one argument, the number of the subroutine to execute in
Private/Subrs.  

0x0b	Retn		- ==> -
	return from subroutine.  All elements of Subrs end with this
operation.  

0x0c	LongOp
	followed by another operation code, as described below.

0x0d *	Metrics		lsb_x width_x ==> -
	takes two arguments:  the left side bearing, and width.  This
information is used (with the y values of each assumed zero) if it is
not overrided by an element in the font dictionary's Metrics entry.
This is usually the first operation executed by a CharString routine.
The internal currentpoint is set to the left side bearing.

0x0e	Finish		- ==> (stack no longer exists)
	clean up and either fill or stroke the path (depending on
PaintType), grestore, and exit.  Apparently, font cache information is
determined here for all PaintTypes except 3.  Fonts of PaintType 3
would call setcachedevice before executing any rendering operations,
and would exit with QuickFinish.  Some of the operations labeled here
with ?'s are likely to be fill and stroke, for use only by PaintType 3
fonts.

0x0f *	moveto		x y ==> -
0x10 *	lineto		x y ==> -
0x11 *	curveto		x1 y1 x2 y2 x3 y3 ==> -
0x12	min		a b ==> min(a, b)
0x13 *		? 26c8c6(3fe0000000000000) ?			- ==> -
0x14 *	newpath		- ==> -
0x15 *	rmoveto		dx dy ==> -
0x16 *	rhmoveto	dx ==> -
0x17 *		? set two bits of something in gstate ?		ferd ==> -
0x18	mul		a b ==> a*b
0x19	strokewidth	(variable)
0x1a	baseline	(variable)
0x1b	capheight	(variable)
0x1c	bover		(variable)

0x1e *	htovrspline	dx1 dx2 dy2 dy3 ==> -
0x1f *	vtohrspline	dy1 dx2 dy2 dx3 ==> -
	these take 4 args instead of six, set the remaining two to 0,
and call rspline.  The curves are constrained to start and end either
vertically or horizontally.

		Long Operations

0x00 *		? toggle something and remember... strange. ?	- ==> -
	this operation appears around some subrs.  sometimes it is
outside the call, and sometimes inside the subr itself.  it always
appears in pairs.  the first call to it sets a value to zero.  the
second call sets it to some function of the currentpoint.  the value
is used to modify all of the coordinates somehow, apparently in
conjunction with the non-linear scaling, but only when other
conditions are met. 

0x01 *	HMHint		x1 width1 x2 width2 x3 width3 ==> -
0x02 *	VMHint		y1 height1 y2 height2 y3 height3 ==> -
	These each take 6 args and appear to encode information for 3
position/value pairs.  See HHint above.


0x03 *		? something about MinFeature ?
0x04 *	arc		x y r ang1 ang2 ==> -
0x05 *		? 1 arg to 26a9f4 ?	ferd ==> -

0x06 *	Accent		ferd x y base accent ==> (no stack)
	Used to create composite characters.  Executes the character
routine corresponding to base, then adjusts the current position by x
and y, and executes the character routine corresponding to accent.
Base and accent are character codes (0-255).  This terminates
execution for this character.  First arg is unclear, but modifies the
x position of the accent character somehow.

0x07 *	LongMetrics	lsbx lsby widthx widthy ==> -
	same as Metrics, but specifies y values as well.

0x08 *	setcachedevice	llx lly urx ury ==> -
	character width is taken from the metric information, so only
4 args are required.  the bounding box is expanded by strokewidth/2 on
all sides before being passed to the actual routine.  Presumably only
used by PaintType 3 fonts.

0x09 *	QuickFinish	- ==> (no stack)
	exit without cleaning up or stroking or filling.  just grestore.

0x0a	add		a b ==> a+b
0x0b	sub		a b ==> a-b
0x0c	div		a b ==> a/b
0x0d	max		a b ==> max(a, b)
0x0e	neg		a ==> -a
0x0f	TestAdd		a b c d ==> b > c ? a + d : a

0x10	OtherSubrs	a1 a2 a3 ... an n index ==> -
	call directly to PostScript code.  top of stack is index of
code to call, next is number of args to transfer to operand stack,
followed by the args to be transferred.

0x11	StackShift	- ==> n
	move a number from the operand stack to the internal stack.

0x12	decend		(variable)
0x13	ascend		(variable)
0x14	overshoot	(variable)
0x15 *		? set two bits of something in gstate ?		ferd ==> -
0x16	xover		(variable)
0x17	capover		(variable)
0x18	aover		(variable)
0x19	halfsw		(variable)

0x1a	PixelRound
	round a value to an even boundary in device space.  this is
just a guess, not verified.

0x1b *	arcn		x y r ang1 ang2 ==> -
0x1c	exch		a b ==> b a
0x1d	index		an ... a1 a0 n ==> an ... a1 a0 an

0x1e *	VHintRound	bottom vwidth ==> -
0x1f *	HHintRound	left hwidth ==> -
	Same as VHint and HHint, except the width is sent to the
pixel round routine.  Additionally, these will take negative widths
and deal with them correctly, the others might not.

0x20 **	currentpoint	- ==> x y
	after pushing the coordinates onto the top of the stack, the
stack pointer is set to point at the bottom of the stack.  presumably
this should only be used when the stack is clear.  in any case, no
math can be performed on these values, as the stack is `empty' when
they are there.  this might be a bug, as I suspect these were meant to
be passed to Qmoveto, but they can never get there.  moveto, however
will work correctly.

0x21 **	Qmoveto		x y ==> -
	doesn't actually call moveto, just remembers new position
internally.  the arguments are poped from the top of the stack, and
then the stack is cleared.

Re: [TUHS] troff was not so widely usable

[Jon Forrest]

On 2/11/2021 5:06 AM, John Gilmore wrote:

> This reminded me of a project that I and a small team did in the 1980s.
> We were licensees of Sun's NeWS source code, and we wanted our software
> to be able to use the wide variety of fonts sold commercially by Adobe
> and font design companies.  The problem was, they were encoded in Adobe
> Type 1 font definitions, which Adobe considered a proprietary trade
> secret. 
> 
> Our team ended up pulling the ROMs out of an original LaserWriter, and
> writing and improving a 68000 disassembler.  One of our team members
> read the code, figured out which parts handled these fonts, and how it
> decoded them.  He wrote that down in his own words in a plain text
> document, not a program, following the prevailing court decisions about
> how to avoid copyright issues while reverse-engineering a trade secret.
> Ultimately, we released that document to some interested people, so that
> others could implement support for Type 1 fonts.  Shortly afterward,
> Adobe magnanimously decided to "release the specification", as Wikipedia
> says. 

I always thought the Prof. Michael Harrison and his group in the
CS Dept. at UC Berkeley were the first to do this. I found a reference
to this in

https://books.google.com/books?id=IToEAAAAMBAJ&pg=PT7&lpg=PT7&dq=michael++harrison+berkeley+postscript+fonts#v=onepage&q=michael%20%20harrison%20berkeley%20postscript%20fonts&f=false

Plus, Mike told me personally that this is what happened.

Jon

Re: [TUHS] troff was not so widely usable

[John Cowan]

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

On Thu, Feb 11, 2021 at 12:34 PM Jon Forrest <nobozo@gmail.com> wrote:


> I always thought the Prof. Michael Harrison and his group in the
> CS Dept. at UC Berkeley were the first to do this. I found a reference
> to this in
>
>
> https://books.google.com/books?id=IToEAAAAMBAJ&pg=PT7&lpg=PT7&dq=michael++harrison+berkeley+postscript+fonts#v=onepage&q=michael%20%20harrison%20berkeley%20postscript%20fonts&f=false


"It steam-engines when it comes steam-engine time."



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
How they ever reached any conclusion at all is starkly unknowable
to the human mind.        --"Backstage Lensman", Randall Garrett

[-- Attachment #2: Type: text/html, Size: 2019 bytes --]

Re: [TUHS] troff was not so widely usable

[Rich Morin]

I've heard stories about a very high speed dot matrix printer used (IIRC) at Lawrence Berkeley Laboratory.  Apparently, it used a bank of Hydrogen Thyratrons to multiplex high voltage onto a set of metal needles.  The resulting sparks burned tiny black holes into the paper at 24K LPM.

It occurs to me that it could probably have been used for graphics, typesetting, and such, but I dunno.  Might anyone here be able to talk about (or provide links about) this beast?

-r

Re: [TUHS] The UNIX Command Language (1976)

[jason-tuhs]

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


> "The UNIX Command Language is the first-ever paper published on the Unix 
> shell. It was written by Ken Thompson in 1976."
> 
> https://github.com/susam/tucl

Thanks for that.

This reminded me that the Thompson shell used goto for flow control, which 
I had forgotten.

Bourne commented on the omission of goto from the Bourne shell, "I 
eliminated goto in favour of flow control primitives like if and for. 
This was also considered rather radical departure from the existing 
practice."

Was this decision contentious at all?  Was there a specific reason for 
goto's exclusion in the Bourne shell?


Thanks.


  -Jason

Re: [TUHS] The UNIX Command Language (1976)

[Jon Steinhart]

jason-tuhs@shalott.net writes:
>
> Bourne commented on the omission of goto from the Bourne shell, "I 
> eliminated goto in favour of flow control primitives like if and for. 
> This was also considered rather radical departure from the existing 
> practice."
>
> Was this decision contentious at all?  Was there a specific reason for 
> goto's exclusion in the Bourne shell?

I don't remember if this story has been told here before or not but I got
it from Steve a few months ago.  Ever wonder by the shell was symmetrical
with if and fi, case and esac, but then had do and done?  Reason was that
by the time Steve wrote the shell, Ken had written the od command and dug
in his heels and wouldn't change the name.

Jon

Re: [TUHS] The UNIX Command Language (1976)

[Steve Nickolas]

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

On Mon, 30 Nov 2020, jason-tuhs@shalott.net wrote:

>
>> "The UNIX Command Language is the first-ever paper published on the Unix 
>> shell. It was written by Ken Thompson in 1976."
>> 
>> https://github.com/susam/tucl
>
> Thanks for that.
>
> This reminded me that the Thompson shell used goto for flow control, which I 
> had forgotten.
>
> Bourne commented on the omission of goto from the Bourne shell, "I eliminated 
> goto in favour of flow control primitives like if and for. This was also 
> considered rather radical departure from the existing practice."
>
> Was this decision contentious at all?  Was there a specific reason for goto's 
> exclusion in the Bourne shell?
>
>
> Thanks.
>
>
> -Jason

My personal opinion is that the way the Bourne shell handled flow control 
is a lot easier to code for (since I wrote a version of COMMAND.COM, and 
it has to have a "goto" command, and all the hairiness that goes with 
needing to be able to random-seek a shell script).

-uso.

Re: [TUHS] The UNIX Command Language (1976)

[Jim Capp]

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

Is it possible the elimination of the GOTO statement in the Bourne Shell 
was related to a Letter to the Editor in Communications of the ACM, March 1968: 

"Go To Statement Considered Harmful," by E. Dijkstra. 

Jim 




From: jason-tuhs@shalott.net 
To: tuhs@minnie.tuhs.org 
Sent: Monday, November 30, 2020 10:59:18 PM 
Subject: Re: [TUHS] The UNIX Command Language (1976) 


> "The UNIX Command Language is the first-ever paper published on the Unix 
> shell. It was written by Ken Thompson in 1976." 
> 
> https://github.com/susam/tucl 

Thanks for that. 

This reminded me that the Thompson shell used goto for flow control, which 
I had forgotten. 

Bourne commented on the omission of goto from the Bourne shell, "I 
eliminated goto in favour of flow control primitives like if and for. 
This was also considered rather radical departure from the existing 
practice." 

Was this decision contentious at all? Was there a specific reason for 
goto's exclusion in the Bourne shell? 


Thanks. 


-Jason 

[-- Attachment #2: Type: text/html, Size: 1502 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Toby Thain]

On 2020-12-01 10:09 a.m., Jim Capp wrote:
> Is it possible the elimination of the GOTO statement in the Bourne Shell
> was related to a Letter to the Editor in Communications of the ACM,
> March 1968:
> "Go To Statement Considered Harmful," by E. Dijkstra.
> 

Broadly connected to the rise of Structured Programming -- which we take
fully for granted today.

The same movement, and the popularity of Pascal, which was very
competitive with C as an applications language, would have motivated the
inclusion of what were at the time considered "high level" control
structures, in C: do/while/for and block structuring.

--Toby


> Jim
> 
> 
> ------------------------------------------------------------------------
> *From: *jason-tuhs@shalott.net
> *To: *tuhs@minnie.tuhs.org
> *Sent: *Monday, November 30, 2020 10:59:18 PM
> *Subject: *Re: [TUHS] The UNIX Command Language (1976)
> 
> 
>> "The UNIX Command Language is the first-ever paper published on the Unix
>> shell. It was written by Ken Thompson in 1976."
>>
>> https://github.com/susam/tucl
> 
> Thanks for that.
> 
> This reminded me that the Thompson shell used goto for flow control, which
> I had forgotten.
> 
> Bourne commented on the omission of goto from the Bourne shell, "I
> eliminated goto in favour of flow control primitives like if and for.
> This was also considered rather radical departure from the existing
> practice."
> 
> Was this decision contentious at all?  Was there a specific reason for
> goto's exclusion in the Bourne shell?
> 
> 
> Thanks.
> 
> 
>   -Jason

Re: [TUHS] The UNIX Command Language (1976)

[arnold]

In the late 70s and early 80s, structured programming was on the
ascension, but had not completely captured the minds of all computer
scientists and programmers. (cf. Knuth's "Structure Programming with
Goto Statements" article.)

It was recognized that goto was not necessary if one had proper control
structures in a language (if/else, while), and that code with no (or
minimal) gotos was easier to read and understand.

So this kind of thing was "in the air" when Bourne wrote the V7 shell.
If he's on this list, it'd be nice to hear directly from the source. :-)

HTH,

Arnold

Jim Capp <jcapp@anteil.com> wrote:

> Is it possible the elimination of the GOTO statement in the Bourne Shell 
> was related to a Letter to the Editor in Communications of the ACM, March 1968: 
>
> "Go To Statement Considered Harmful," by E. Dijkstra. 
>
> Jim 
>
>
> From: jason-tuhs@shalott.net 
> To: tuhs@minnie.tuhs.org 
> Sent: Monday, November 30, 2020 10:59:18 PM 
> Subject: Re: [TUHS] The UNIX Command Language (1976) 
>
> > "The UNIX Command Language is the first-ever paper published on the Unix 
> > shell. It was written by Ken Thompson in 1976." 
> > 
> > https://github.com/susam/tucl 
>
> Thanks for that. 
>
> This reminded me that the Thompson shell used goto for flow control, which 
> I had forgotten. 
>
> Bourne commented on the omission of goto from the Bourne shell, "I 
> eliminated goto in favour of flow control primitives like if and for. 
> This was also considered rather radical departure from the existing 
> practice." 
>
> Was this decision contentious at all? Was there a specific reason for 
> goto's exclusion in the Bourne shell? 
>
> Thanks. 
>
> -Jason 

Re: [TUHS] The UNIX Command Language (1976)

[Warner Losh]

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

On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:

> It was recognized that goto was not necessary if one had proper control
> structures in a language (if/else, while), and that code with no (or
> minimal) gotos was easier to read and understand.
>

This is true for simple flow control. However, when you had to break out of
multiple levels, or continue not the inner loop, but the middle loop, the
use of extra booleans sure made the code less understandable than a 'goto'
a label that stood in for that purpose... This was something that wasn't
well understood by language designers, and even today C and C++ neither
have good flow control beyond the basics. Even though both break and
continue could take an optional count without breaking old code....

Warner

[-- Attachment #2: Type: text/html, Size: 1144 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[arnold]

> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:
> > It was recognized that goto was not necessary if one had proper control
> > structures in a language (if/else, while), and that code with no (or
> > minimal) gotos was easier to read and understand.

Warner Losh <imp@bsdimp.com> wrote:
> This is true for simple flow control. However, when you had to break out of
> multiple levels, or continue not the inner loop, but the middle loop, the
> use of extra booleans sure made the code less understandable than a 'goto'
> a label that stood in for that purpose... This was something that wasn't
> well understood by language designers, and even today C and C++ neither
> have good flow control beyond the basics. Even though both break and
> continue could take an optional count without breaking old code....

Quite true. Modern Bourne shells let you supply a number to break and
continue to specify how many loops to break.  Ada, or maybe it was one of
the Modula-X languages, let you put a label on a loop so that you could
say `continue outer' or `break outer' and not need the booleans.

This is something that newer languages (C#, Java, Go, ...) could have picked
up but didn't, which I think is too bad.

Arnold

Re: [TUHS] The UNIX Command Language (1976)

[Rob Pike]

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

Go lets you say "Loop: for ..." and then "break Loop".

-rob


On Wed, Dec 2, 2020 at 3:40 AM <arnold@skeeve.com> wrote:

> > On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:
> > > It was recognized that goto was not necessary if one had proper control
> > > structures in a language (if/else, while), and that code with no (or
> > > minimal) gotos was easier to read and understand.
>
> Warner Losh <imp@bsdimp.com> wrote:
> > This is true for simple flow control. However, when you had to break out
> of
> > multiple levels, or continue not the inner loop, but the middle loop, the
> > use of extra booleans sure made the code less understandable than a
> 'goto'
> > a label that stood in for that purpose... This was something that wasn't
> > well understood by language designers, and even today C and C++ neither
> > have good flow control beyond the basics. Even though both break and
> > continue could take an optional count without breaking old code....
>
> Quite true. Modern Bourne shells let you supply a number to break and
> continue to specify how many loops to break.  Ada, or maybe it was one of
> the Modula-X languages, let you put a label on a loop so that you could
> say `continue outer' or `break outer' and not need the booleans.
>
> This is something that newer languages (C#, Java, Go, ...) could have
> picked
> up but didn't, which I think is too bad.
>
> Arnold
>

[-- Attachment #2: Type: text/html, Size: 1988 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[arnold]

If I knew that I forgot it (obviously).  Thanks for letting me know.
Yet another reason to move to Go.

Has it been there since Day 1?  Just wondering.

Thanks,

Arnold

Rob Pike <robpike@gmail.com> wrote:

> Go lets you say "Loop: for ..." and then "break Loop".
>
> -rob

Re: [TUHS] The UNIX Command Language (1976)

[Rob Pike]

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

Yes.

-rob


On Wed, Dec 2, 2020 at 6:08 PM <arnold@skeeve.com> wrote:

> If I knew that I forgot it (obviously).  Thanks for letting me know.
> Yet another reason to move to Go.
>
> Has it been there since Day 1?  Just wondering.
>
> Thanks,
>
> Arnold
>
> Rob Pike <robpike@gmail.com> wrote:
>
> > Go lets you say "Loop: for ..." and then "break Loop".
> >
> > -rob
>
>

[-- Attachment #2: Type: text/html, Size: 828 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Steffen Nurpmeso]

arnold@skeeve.com wrote in
 <202012011639.0B1GdjcD031722@freefriends.org>:
 |> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:
 |>> It was recognized that goto was not necessary if one had proper control
 |>> structures in a language (if/else, while), and that code with no (or
 |>> minimal) gotos was easier to read and understand.
 |
 |Warner Losh <imp@bsdimp.com> wrote:
 |> This is true for simple flow control. However, when you had to break \
 |> out of
 |> multiple levels, or continue not the inner loop, but the middle loop, the
 |> use of extra booleans sure made the code less understandable than \
 |> a 'goto'
 |> a label that stood in for that purpose... This was something that wasn't
 |> well understood by language designers, and even today C and C++ neither
 |> have good flow control beyond the basics. Even though both break and
 |> continue could take an optional count without breaking old code....
 |
 |Quite true. Modern Bourne shells let you supply a number to break and
 |continue to specify how many loops to break.  Ada, or maybe it was one of
 |the Modula-X languages, let you put a label on a loop so that you could
 |say `continue outer' or `break outer' and not need the booleans.

Bah, and perl could and obsoleted it, or at least jumping into
blocks (not crossing initializers)!  You now write code like

      my $ogoditisanewperl = 0;

      if(defined($nl = $self->begin_line)){
         $self->begin_line(undef);
         $self->seen_endl(1);
         $ogoditisanewperl = 1 #goto jumpin;
      }

      while($ogoditisanewperl || ($nl = readline $self->infh)){
         if(!$ogoditisanewperl){
            ++${$self->__lineno};
            $self->seen_endl($nl =~ s/(.*?)\s+$/$1/)
         }
         $ogoditisanewperl = 0; #jumpin:

or even have to work with closures or whatever, or the worst, code
duplication.

 |This is something that newer languages (C#, Java, Go, ...) could have \
 |picked
 |up but didn't, which I think is too bad.

Never without my goto:, and if it is only to break to error
handling and/or staged destruction of local variables after
initialization failures.  Traumatic school impression, finding
yourself locked in some PASCAL if condition, and no way to go to.

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

Re: [TUHS] The UNIX Command Language (1976)

[Bakul Shah]

On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> 
> Never without my goto:, and if it is only to break to error
> handling and/or staged destruction of local variables after
> initialization failures.  Traumatic school impression, finding
> yourself locked in some PASCAL if condition, and no way to go to.

Pascal had goto. You can even do a non-local goto!

In Go you don't need goto for the sort of thing you and McVoy
talked about due to its defer statement and GC. Now granted
GC may be too big of a hammer for C/C++ but a future C/C++
add defer gainfully as the defer pattern is pretty common.
For example, mutex lock and unlock.

But I have mixed feelings about goto vs continue/break. A nested
loop with multiple continue/break can be as obscure. 

Re: [TUHS] The UNIX Command Language (1976)

[Dan Cross]

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

On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah <bakul@iitbombay.org> wrote:

> On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> > Never without my goto:, and if it is only to break to error
> > handling and/or staged destruction of local variables after
> > initialization failures.  Traumatic school impression, finding
> > yourself locked in some PASCAL if condition, and no way to go to.
>
> Pascal had goto.


Pascal also had to go. (Thanks...I'm here all week.)

You can even do a non-local goto!
>
> In Go you don't need goto for the sort of thing you and McVoy
> talked about due to its defer statement and GC. Now granted
> GC may be too big of a hammer for C/C++ but a future C/C++
> add defer gainfully as the defer pattern is pretty common.
> For example, mutex lock and unlock.
>

C++ has had something analogous for some time: destructors that run when an
object goes out of scope. Scope guards to do things like close files and
auto-release locks on exiting a critical section are pretty common in that
world, and in general, preferable to many of the alternatives (either
deeply nested conditionals or banks of labels and `goto fail1;` `goto
fail2;` etc, that successively release resources on return; the latter is
basically hand-rolling what the language does automatically for you, and
has been the cause of at least security-related bug: apple's "goto fail"
bug in their SSL implementation).

There's still no easy way to break out of nested loops, though.

But I have mixed feelings about goto vs continue/break. A nested
> loop with multiple continue/break can be as obscure.
>

I submit that it's in how you write it: if the set of conditions on which
one would break/continue are explicit and early in the loop body, it can be
a very expressive way to write something. But like any tool, it can be
abused.

Along those lines, it's always been interesting to me the way that
Dijkstra's statement about goto must have influenced language design. The
original "GOTO Statement Considered Harmful" note was quite damning, but I
wonder if it meant to be: it strikes me that the really dangerous thing
about "goto" isn't its mere existence or even its use, but rather, it's
unconstrained use when better alternatives exist in the language. As one
can observe in well-written C code, judicious use of `goto` can be quite
elegant in comparison to the alternative.

I've often wondered whether  language designers, mindful of the pitfalls of
`goto`, eventually took the most useful patterns of its usage and extracted
them to stand on their own. Early returns from functions are an obvious
example, but so are `break` and `continue` and one might argue exceptions
fall into the same category. It strikes me that as we gain ever greater
experience with languages, we find more and more examples of things one
routinely does using a blunt instrument like goto, and we refine those to
first-class features of the language.

I think it's also illustrative of how social pressure can influence one to
avoid "dangerous" patterns in favor of these language features. C isn't
inherently more dangerous because it has a goto statement and labels; most
of the time, one doesn't bother to use goto because alternatives exist that
are more natural and fill the same role (continue, break, return, etc).

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 4361 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[John Cowan]

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

On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah <bakul@iitbombay.org> wrote:

Along those lines, it's always been interesting to me the way that
> Dijkstra's statement about goto must have influenced language design. The
> original "GOTO Statement Considered Harmful" note was quite damning, but I
> wonder if it meant to be: it strikes me that the really dangerous thing
> about "goto" isn't its mere existence or even its use, but rather, it's
> unconstrained use when better alternatives exist in the language. As one
> can observe in well-written C code, judicious use of `goto` can be quite
> elegant in comparison to the alternative.
>

D-1stra originally sent "Go to [...]" to CACM as a paper entitled "A Case
Against The Go To Statement".  But the editor, who was Niklaus Wirth,
thought it important to publish it quickly, so he turned it into a letter
to the editor and retitled it.

[-- Attachment #2: Type: text/html, Size: 1942 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[scj]

When I wrote yacc, my first thought was to use goto's when implementing 
the finite state machine that is the heart of the parser.  That's how 
FSM's work! I got the code written, but the C compiler complained and 
wouldn't compile.  It turned out that, while goto was implemented in C, 
you could only have 10 of them!  So I had to use a switch statement.

I also recently came upon one of my first C programs -- I wrote a "go 
fish" game for my son as a practice in using the language.  Reading the 
code was most instructive:
    1.  I had used FOUR gotos!   I can't remember the last time I wrote a 
goto...
    2.  The program had a bug -- char being used as an int.  Gave an 
advantage to the player.
    3.  The game was surprisingly hard to beat.  I had to add a "dumb me 
down" flag because my kids never won.

I think the game was distributed in some of the early releases.  At one 
point, at a conference, the speaker accused the game of cheating!  The 
game was just very good at remembering that if the player had asked it 
for a 6, and then it drew a 6 later, it would ask the player for 6 
again.




On 2020-12-01 08:39, arnold@skeeve.com wrote:
>> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:
>> > It was recognized that goto was not necessary if one had proper control
>> > structures in a language (if/else, while), and that code with no (or
>> > minimal) gotos was easier to read and understand.

Re: [TUHS] The UNIX Command Language (1976)

[Larry McVoy]

On Tue, Dec 01, 2020 at 09:24:17AM -0700, Warner Losh wrote:
> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:
> 
> > It was recognized that goto was not necessary if one had proper control
> > structures in a language (if/else, while), and that code with no (or
> > minimal) gotos was easier to read and understand.
> >
> 
> This is true for simple flow control. However, when you had to break out of
> multiple levels, or continue not the inner loop, but the middle loop, the
> use of extra booleans sure made the code less understandable than a 'goto'
> a label that stood in for that purpose... This was something that wasn't
> well understood by language designers, and even today C and C++ neither
> have good flow control beyond the basics. Even though both break and
> continue could take an optional count without breaking old code....

Probably need to move this to COFF... but.

Yeah, I've tons of examples of

int
somefunc()
{
	char	*a = 0;
	int	*b = 0;
	flat	*c = 0;
	int	ret = 0;

	if (something) {
		a = malloc(something);
	} else {
		ret = NO_SOMETHING;
		goto error;
    	}
	// same for b, c
error:
	unless (ret) ret = GENERIC_ERROR;
	if (a) free(a);
	if (b) free(b);
	if (c) free(c);
	return (ret);
}

and you can handle a lot of simple cases that way.  But sometimes the 
unraveling is more difficult than a simple free so I might have a
	goto unravel;
instead of the generic
	goto out;

I love goto *if* you figure out a pattern for using it and stick to that.
For the people who don't like goto, what is your feeling on longjmp()?

Re: [TUHS] The UNIX Command Language (1976)

[Dave Horsfall]

On Tue, 1 Dec 2020, Jim Capp wrote:

> Is it possible the elimination of the GOTO statement in the Bourne 
> Shellwas related to a Letter to the Editor in Communications of the ACM, 
> March 1968: "Go To Statement Considered Harmful," by E. Dijkstra.

And then there was the story of Professor Goto (a Japanese citizen and 
computer bod) who complained that everyone was trying to eliminate him :-)

-- Dave

Re: [TUHS] The UNIX Command Language (1976)

[John Cowan]

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

On Tue, Dec 1, 2020 at 3:14 PM Dave Horsfall <dave@horsfall.org> wrote:


> And then there was the story of Professor Goto (a Japanese citizen and
> computer bod) who complained that everyone was trying to eliminate him :-)
>

But cheerfully so, according to Knuth.  He is also known for the invention
of hash consing.  Knuth's article "Structured programming with goto
statements" <http://www.clifford.at/cfun/cliffdev/p261-knuth.pdf> is a
great discussion of all the reasons you'd want to use goto in languages
with just conditionals and while loops:  error exits, jumping out of nested
tests, jumping out of a nest of conditionals and break/continue (both
essentially kinds of static catch tags), loops iterated n-and-a-half-times
(break will do this, but it's over-powered), tail recursion, "encoding
boolean variables in the program counter", coroutines.  There are also such
things as fast linear search by putting the searched-for value at the end
of the array being searched, and what boils down to Lisp macros ("allowing
an optimizing compiler to express its optimizations in the source
language").

On Tue, Dec 1, 2020 at 3:39 PM Bakul Shah <bakul@iitbombay.org> wrote:


> But I have mixed feelings about goto vs continue/break. A nested
> loop with multiple continue/break can be as obscure.


I think if the loops are labeled rather than the destinations, and you use
"next foo" instead of "continue" and "last foo" instead of "break", it's
all quite readable.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Sir, I quite agree with you, but what are we two against so many?
    --George Bernard Shaw,
         to a man booing at the opening of _Arms and the Man_

[-- Attachment #2: Type: text/html, Size: 3317 bytes --]

Re: [TUHS] The UNIX Command Language (1976)

[Tyler Adams]

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

"The most exotic feature of the Shell is its ability to connect the
standard output of one command directly to the standard input of
another. *Again,
neither program is aware that such things are going on.* In the example"

So sad that many shell programs today break this abstraction barrier :/ Was
there a watershed moment when people started doing this, or people just
always couldn't resist the "convenience" of typing less?


 Tyler


On Mon, Nov 30, 2020 at 5:18 AM Joachim via TUHS <tuhs@minnie.tuhs.org>
wrote:

> Apologies if this has already been linked here.
>
> "The UNIX Command Language is the first-ever paper published on the Unix
> shell. It was written by Ken Thompson in 1976."
>
> https://github.com/susam/tucl
>
>
> Joachim
>

[-- Attachment #2: Type: text/html, Size: 2626 bytes --]

Re: [TUHS] troff was not so widely usable

[Nelson H. F. Beebe]

Recent discussions on this list are about the problem getting fonts
for typesetting before there was an industry to provide them.  Noted
font designer Chuck Bigelow has written about the subject here:

	Notes on typeface protection
	TUGboat 7(3) 146--151 October 1986
	https://tug.org/TUGboat/tb07-3/tb16bigelow.pdf

Other TUGboat papers by him and his design partner, Kris Holmes, might
be of reader interest:

	Lucida and {\TeX}: lessons of logic and history
	https://tug.org/TUGboat/tb15-3/tb44bigelow.pdf

	About the DK versions of Lucida
	https://tug.org/TUGboat/tb36-3/tb114bigelow.pdf

	A short history of the Lucida math fonts
	https://tug.org/TUGboat/tb37-2/tb116bigelow-lucidamath.pdf

	Science and history behind the design of Lucida
	https://tug.org/TUGboat/tb39-3/tb123bigelow-lucida.pdf

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------