The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] The UNIX Command Language (1976)
@ 2020-11-30  3:10 Joachim via TUHS
  2020-11-30  8:30 ` Thomas Paulsen
                   ` (4 more replies)
  0 siblings, 5 replies; 91+ messages in thread
From: Joachim via TUHS @ 2020-11-30  3:10 UTC (permalink / raw)
  To: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30  3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS
@ 2020-11-30  8:30 ` Thomas Paulsen
  2020-11-30 13:36 ` Brantley Coile
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 91+ messages in thread
From: Thomas Paulsen @ 2020-11-30  8:30 UTC (permalink / raw)
  To: Joachim; +Cc: tuhs

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30  3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS
  2020-11-30  8:30 ` Thomas Paulsen
@ 2020-11-30 13:36 ` Brantley Coile
  2020-11-30 15:12   ` Tom Ivar Helbekkmo via TUHS
  2020-11-30 15:52 ` Clem Cole
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 91+ messages in thread
From: Brantley Coile @ 2020-11-30 13:36 UTC (permalink / raw)
  To: Joachim; +Cc: TUHS main list

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


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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 13:36 ` Brantley Coile
@ 2020-11-30 15:12   ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 0 replies; 91+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2020-11-30 15:12 UTC (permalink / raw)
  To: Brantley Coile; +Cc: TUHS main list

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30  3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS
  2020-11-30  8:30 ` Thomas Paulsen
  2020-11-30 13:36 ` Brantley Coile
@ 2020-11-30 15:52 ` Clem Cole
  2020-11-30 16:25   ` Dan Cross
  2020-11-30 16:37   ` Larry McVoy
  2020-12-01  3:59 ` [TUHS] The UNIX Command Language (1976) jason-tuhs
  2020-12-01 16:04 ` Tyler Adams
  4 siblings, 2 replies; 91+ messages in thread
From: Clem Cole @ 2020-11-30 15:52 UTC (permalink / raw)
  To: Joachim; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 15:52 ` Clem Cole
@ 2020-11-30 16:25   ` Dan Cross
  2020-11-30 16:38     ` Warner Losh
  2020-11-30 16:37   ` Larry McVoy
  1 sibling, 1 reply; 91+ messages in thread
From: Dan Cross @ 2020-11-30 16:25 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 15:52 ` Clem Cole
  2020-11-30 16:25   ` Dan Cross
@ 2020-11-30 16:37   ` Larry McVoy
  2020-11-30 16:54     ` Clem Cole
  1 sibling, 1 reply; 91+ messages in thread
From: Larry McVoy @ 2020-11-30 16:37 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

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 

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 16:25   ` Dan Cross
@ 2020-11-30 16:38     ` Warner Losh
  2020-11-30 16:41       ` Dan Cross
  0 siblings, 1 reply; 91+ messages in thread
From: Warner Losh @ 2020-11-30 16:38 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 16:38     ` Warner Losh
@ 2020-11-30 16:41       ` Dan Cross
  0 siblings, 0 replies; 91+ messages in thread
From: Dan Cross @ 2020-11-30 16:41 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 16:37   ` Larry McVoy
@ 2020-11-30 16:54     ` Clem Cole
  2020-11-30 18:13       ` Theodore Y. Ts'o
                         ` (2 more replies)
  0 siblings, 3 replies; 91+ messages in thread
From: Clem Cole @ 2020-11-30 16:54 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 16:54     ` Clem Cole
@ 2020-11-30 18:13       ` Theodore Y. Ts'o
  2020-11-30 18:25       ` John Cowan
  2021-02-10 20:48       ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods
  2 siblings, 0 replies; 91+ messages in thread
From: Theodore Y. Ts'o @ 2020-11-30 18:13 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 16:54     ` Clem Cole
  2020-11-30 18:13       ` Theodore Y. Ts'o
@ 2020-11-30 18:25       ` John Cowan
  2020-11-30 18:37         ` Clem Cole
  2020-11-30 18:46         ` Nemo Nusquam
  2021-02-10 20:48       ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods
  2 siblings, 2 replies; 91+ messages in thread
From: John Cowan @ 2020-11-30 18:25 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 18:25       ` John Cowan
@ 2020-11-30 18:37         ` Clem Cole
  2020-11-30 20:11           ` arnold
  2020-11-30 18:46         ` Nemo Nusquam
  1 sibling, 1 reply; 91+ messages in thread
From: Clem Cole @ 2020-11-30 18:37 UTC (permalink / raw)
  To: John Cowan; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 18:25       ` John Cowan
  2020-11-30 18:37         ` Clem Cole
@ 2020-11-30 18:46         ` Nemo Nusquam
  1 sibling, 0 replies; 91+ messages in thread
From: Nemo Nusquam @ 2020-11-30 18:46 UTC (permalink / raw)
  To: tuhs

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>


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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 18:37         ` Clem Cole
@ 2020-11-30 20:11           ` arnold
  2020-11-30 21:49             ` Will Senn
  2020-12-01  2:55             ` Jon Steinhart
  0 siblings, 2 replies; 91+ messages in thread
From: arnold @ 2020-11-30 20:11 UTC (permalink / raw)
  To: cowan, clemc; +Cc: tuhs

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 20:11           ` arnold
@ 2020-11-30 21:49             ` Will Senn
  2020-12-01  2:55             ` Jon Steinhart
  1 sibling, 0 replies; 91+ messages in thread
From: Will Senn @ 2020-11-30 21:49 UTC (permalink / raw)
  To: tuhs

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30 20:11           ` arnold
  2020-11-30 21:49             ` Will Senn
@ 2020-12-01  2:55             ` Jon Steinhart
  1 sibling, 0 replies; 91+ messages in thread
From: Jon Steinhart @ 2020-12-01  2:55 UTC (permalink / raw)
  To: tuhs

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

Bill Pollack, No Starch Press.

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30  3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS
                   ` (2 preceding siblings ...)
  2020-11-30 15:52 ` Clem Cole
@ 2020-12-01  3:59 ` jason-tuhs
  2020-12-01  4:03   ` Jon Steinhart
                     ` (2 more replies)
  2020-12-01 16:04 ` Tyler Adams
  4 siblings, 3 replies; 91+ messages in thread
From: jason-tuhs @ 2020-12-01  3:59 UTC (permalink / raw)
  To: 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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01  3:59 ` [TUHS] The UNIX Command Language (1976) jason-tuhs
@ 2020-12-01  4:03   ` Jon Steinhart
  2020-12-01  9:27   ` Steve Nickolas
  2020-12-01 15:09   ` Jim Capp
  2 siblings, 0 replies; 91+ messages in thread
From: Jon Steinhart @ 2020-12-01  4:03 UTC (permalink / raw)
  To: tuhs

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01  3:59 ` [TUHS] The UNIX Command Language (1976) jason-tuhs
  2020-12-01  4:03   ` Jon Steinhart
@ 2020-12-01  9:27   ` Steve Nickolas
  2020-12-01 15:09   ` Jim Capp
  2 siblings, 0 replies; 91+ messages in thread
From: Steve Nickolas @ 2020-12-01  9:27 UTC (permalink / raw)
  To: tuhs

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01  3:59 ` [TUHS] The UNIX Command Language (1976) jason-tuhs
  2020-12-01  4:03   ` Jon Steinhart
  2020-12-01  9:27   ` Steve Nickolas
@ 2020-12-01 15:09   ` Jim Capp
  2020-12-01 15:35     ` Toby Thain
                       ` (2 more replies)
  2 siblings, 3 replies; 91+ messages in thread
From: Jim Capp @ 2020-12-01 15:09 UTC (permalink / raw)
  To: jason-tuhs; +Cc: tuhs

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 15:09   ` Jim Capp
@ 2020-12-01 15:35     ` Toby Thain
  2020-12-01 15:38     ` arnold
  2020-12-01 20:13     ` Dave Horsfall
  2 siblings, 0 replies; 91+ messages in thread
From: Toby Thain @ 2020-12-01 15:35 UTC (permalink / raw)
  To: Jim Capp, jason-tuhs; +Cc: tuhs

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


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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 15:09   ` Jim Capp
  2020-12-01 15:35     ` Toby Thain
@ 2020-12-01 15:38     ` arnold
  2020-12-01 16:24       ` Warner Losh
  2020-12-01 20:13     ` Dave Horsfall
  2 siblings, 1 reply; 91+ messages in thread
From: arnold @ 2020-12-01 15:38 UTC (permalink / raw)
  To: jcapp, jason-tuhs; +Cc: tuhs

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 

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-11-30  3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS
                   ` (3 preceding siblings ...)
  2020-12-01  3:59 ` [TUHS] The UNIX Command Language (1976) jason-tuhs
@ 2020-12-01 16:04 ` Tyler Adams
  4 siblings, 0 replies; 91+ messages in thread
From: Tyler Adams @ 2020-12-01 16:04 UTC (permalink / raw)
  To: Joachim; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 15:38     ` arnold
@ 2020-12-01 16:24       ` Warner Losh
  2020-12-01 16:39         ` arnold
  2020-12-01 16:47         ` Larry McVoy
  0 siblings, 2 replies; 91+ messages in thread
From: Warner Losh @ 2020-12-01 16:24 UTC (permalink / raw)
  To: Arnold Robbins; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 16:24       ` Warner Losh
@ 2020-12-01 16:39         ` arnold
  2020-12-01 20:13           ` Rob Pike
                             ` (2 more replies)
  2020-12-01 16:47         ` Larry McVoy
  1 sibling, 3 replies; 91+ messages in thread
From: arnold @ 2020-12-01 16:39 UTC (permalink / raw)
  To: imp, arnold; +Cc: tuhs

> 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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 16:24       ` Warner Losh
  2020-12-01 16:39         ` arnold
@ 2020-12-01 16:47         ` Larry McVoy
  1 sibling, 0 replies; 91+ messages in thread
From: Larry McVoy @ 2020-12-01 16:47 UTC (permalink / raw)
  To: Warner Losh; +Cc: TUHS main list

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 16:39         ` arnold
@ 2020-12-01 20:13           ` Rob Pike
  2020-12-02  7:08             ` arnold
  2020-12-01 20:20           ` Steffen Nurpmeso
  2020-12-12 19:50           ` scj
  2 siblings, 1 reply; 91+ messages in thread
From: Rob Pike @ 2020-12-01 20:13 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 15:09   ` Jim Capp
  2020-12-01 15:35     ` Toby Thain
  2020-12-01 15:38     ` arnold
@ 2020-12-01 20:13     ` Dave Horsfall
  2020-12-01 20:49       ` John Cowan
  2 siblings, 1 reply; 91+ messages in thread
From: Dave Horsfall @ 2020-12-01 20:13 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 16:39         ` arnold
  2020-12-01 20:13           ` Rob Pike
@ 2020-12-01 20:20           ` Steffen Nurpmeso
  2020-12-01 20:39             ` Bakul Shah
  2020-12-12 19:50           ` scj
  2 siblings, 1 reply; 91+ messages in thread
From: Steffen Nurpmeso @ 2020-12-01 20:20 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

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)

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 20:20           ` Steffen Nurpmeso
@ 2020-12-01 20:39             ` Bakul Shah
  2020-12-01 21:24               ` Dan Cross
  0 siblings, 1 reply; 91+ messages in thread
From: Bakul Shah @ 2020-12-01 20:39 UTC (permalink / raw)
  To: Steffen Nurpmeso; +Cc: tuhs

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. 

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 20:13     ` Dave Horsfall
@ 2020-12-01 20:49       ` John Cowan
  0 siblings, 0 replies; 91+ messages in thread
From: John Cowan @ 2020-12-01 20:49 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 20:39             ` Bakul Shah
@ 2020-12-01 21:24               ` Dan Cross
  2020-12-01 23:44                 ` John Cowan
  0 siblings, 1 reply; 91+ messages in thread
From: Dan Cross @ 2020-12-01 21:24 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 21:24               ` Dan Cross
@ 2020-12-01 23:44                 ` John Cowan
  0 siblings, 0 replies; 91+ messages in thread
From: John Cowan @ 2020-12-01 23:44 UTC (permalink / raw)
  To: Dan Cross; +Cc: Bakul Shah, TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 20:13           ` Rob Pike
@ 2020-12-02  7:08             ` arnold
  2020-12-02  7:29               ` Rob Pike
  0 siblings, 1 reply; 91+ messages in thread
From: arnold @ 2020-12-02  7:08 UTC (permalink / raw)
  To: robpike, arnold; +Cc: tuhs

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


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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-02  7:08             ` arnold
@ 2020-12-02  7:29               ` Rob Pike
  0 siblings, 0 replies; 91+ messages in thread
From: Rob Pike @ 2020-12-02  7:29 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01 16:39         ` arnold
  2020-12-01 20:13           ` Rob Pike
  2020-12-01 20:20           ` Steffen Nurpmeso
@ 2020-12-12 19:50           ` scj
  2 siblings, 0 replies; 91+ messages in thread
From: scj @ 2020-12-12 19:50 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

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.

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

* [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2020-11-30 16:54     ` Clem Cole
  2020-11-30 18:13       ` Theodore Y. Ts'o
  2020-11-30 18:25       ` John Cowan
@ 2021-02-10 20:48       ` Greg A. Woods
  2021-02-10 21:44         ` Larry McVoy
                           ` (2 more replies)
  2 siblings, 3 replies; 91+ messages in thread
From: Greg A. Woods @ 2021-02-10 20:48 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-10 20:48       ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods
@ 2021-02-10 21:44         ` Larry McVoy
  2021-02-10 22:05         ` Clem Cole
  2021-02-10 22:36         ` Jon Steinhart
  2 siblings, 0 replies; 91+ messages in thread
From: Larry McVoy @ 2021-02-10 21:44 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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.

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-10 20:48       ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods
  2021-02-10 21:44         ` Larry McVoy
@ 2021-02-10 22:05         ` Clem Cole
  2021-02-11 21:58           ` Greg A. Woods
  2021-02-10 22:36         ` Jon Steinhart
  2 siblings, 1 reply; 91+ messages in thread
From: Clem Cole @ 2021-02-10 22:05 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-10 20:48       ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods
  2021-02-10 21:44         ` Larry McVoy
  2021-02-10 22:05         ` Clem Cole
@ 2021-02-10 22:36         ` Jon Steinhart
  2021-02-10 23:05           ` George Michaelson
  2 siblings, 1 reply; 91+ messages in thread
From: Jon Steinhart @ 2021-02-10 22:36 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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.

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-10 22:36         ` Jon Steinhart
@ 2021-02-10 23:05           ` George Michaelson
  2021-02-11  0:27             ` Ron Natalie
  0 siblings, 1 reply; 91+ messages in thread
From: George Michaelson @ 2021-02-10 23:05 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Unix Heritage Society mailing list

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.

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-10 23:05           ` George Michaelson
@ 2021-02-11  0:27             ` Ron Natalie
  2021-02-11  0:36               ` Larry McVoy
  2021-02-11  1:53               ` Clem Cole
  0 siblings, 2 replies; 91+ messages in thread
From: Ron Natalie @ 2021-02-11  0:27 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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.




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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  0:27             ` Ron Natalie
@ 2021-02-11  0:36               ` Larry McVoy
  2021-02-11  1:53               ` Clem Cole
  1 sibling, 0 replies; 91+ messages in thread
From: Larry McVoy @ 2021-02-11  0:36 UTC (permalink / raw)
  To: Ron Natalie; +Cc: The Unix Heritage Society mailing list

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?

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  0:27             ` Ron Natalie
  2021-02-11  0:36               ` Larry McVoy
@ 2021-02-11  1:53               ` Clem Cole
  2021-02-11  1:59                 ` Richard Salz
  2021-02-11  2:30                 ` [TUHS] troff was not so widely usable Mary Ann Horton
  1 sibling, 2 replies; 91+ messages in thread
From: Clem Cole @ 2021-02-11  1:53 UTC (permalink / raw)
  To: Ron Natalie; +Cc: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  1:53               ` Clem Cole
@ 2021-02-11  1:59                 ` Richard Salz
  2021-02-11  2:04                   ` George Michaelson
  2021-02-11  2:30                 ` [TUHS] troff was not so widely usable Mary Ann Horton
  1 sibling, 1 reply; 91+ messages in thread
From: Richard Salz @ 2021-02-11  1:59 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  1:59                 ` Richard Salz
@ 2021-02-11  2:04                   ` George Michaelson
  2021-02-11  2:44                     ` Richard Salz
  0 siblings, 1 reply; 91+ messages in thread
From: George Michaelson @ 2021-02-11  2:04 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Unix Heritage Society mailing list

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

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

* Re: [TUHS] troff was not so widely usable
  2021-02-11  1:53               ` Clem Cole
  2021-02-11  1:59                 ` Richard Salz
@ 2021-02-11  2:30                 ` Mary Ann Horton
  2021-02-11  2:52                   ` Larry McVoy
  1 sibling, 1 reply; 91+ messages in thread
From: Mary Ann Horton @ 2021-02-11  2:30 UTC (permalink / raw)
  To: tuhs

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  2:04                   ` George Michaelson
@ 2021-02-11  2:44                     ` Richard Salz
  2021-02-11  3:02                       ` Steve Nickolas
  2021-02-11 16:55                       ` Ron Natalie
  0 siblings, 2 replies; 91+ messages in thread
From: Richard Salz @ 2021-02-11  2:44 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable
  2021-02-11  2:30                 ` [TUHS] troff was not so widely usable Mary Ann Horton
@ 2021-02-11  2:52                   ` Larry McVoy
  2021-02-11  6:42                     ` Andrew Hume
  0 siblings, 1 reply; 91+ messages in thread
From: Larry McVoy @ 2021-02-11  2:52 UTC (permalink / raw)
  To: Mary Ann Horton; +Cc: tuhs

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 

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  2:44                     ` Richard Salz
@ 2021-02-11  3:02                       ` Steve Nickolas
  2021-02-11  4:07                         ` Toby Thain
  2021-02-11 16:55                       ` Ron Natalie
  1 sibling, 1 reply; 91+ messages in thread
From: Steve Nickolas @ 2021-02-11  3:02 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Unix Heritage Society mailing list

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.

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  3:02                       ` Steve Nickolas
@ 2021-02-11  4:07                         ` Toby Thain
  0 siblings, 0 replies; 91+ messages in thread
From: Toby Thain @ 2021-02-11  4:07 UTC (permalink / raw)
  To: Steve Nickolas, Richard Salz; +Cc: The Unix Heritage Society mailing list

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.


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

* Re: [TUHS] troff was not so widely usable
  2021-02-11  2:52                   ` Larry McVoy
@ 2021-02-11  6:42                     ` Andrew Hume
  2021-02-11  7:12                       ` Rob Pike
  0 siblings, 1 reply; 91+ messages in thread
From: Andrew Hume @ 2021-02-11  6:42 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

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

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

* Re: [TUHS] troff was not so widely usable
  2021-02-11  6:42                     ` Andrew Hume
@ 2021-02-11  7:12                       ` Rob Pike
  2021-02-11 13:06                         ` John Gilmore
  0 siblings, 1 reply; 91+ messages in thread
From: Rob Pike @ 2021-02-11  7:12 UTC (permalink / raw)
  To: Andrew Hume; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable
  2021-02-11  7:12                       ` Rob Pike
@ 2021-02-11 13:06                         ` John Gilmore
  2021-02-11 17:34                           ` Jon Forrest
  0 siblings, 1 reply; 91+ messages in thread
From: John Gilmore @ 2021-02-11 13:06 UTC (permalink / raw)
  To: Andrew Hume, TUHS main list

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.

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11  2:44                     ` Richard Salz
  2021-02-11  3:02                       ` Steve Nickolas
@ 2021-02-11 16:55                       ` Ron Natalie
  2021-02-11 20:27                         ` John Cowan
  1 sibling, 1 reply; 91+ messages in thread
From: Ron Natalie @ 2021-02-11 16:55 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable
  2021-02-11 13:06                         ` John Gilmore
@ 2021-02-11 17:34                           ` Jon Forrest
  2021-02-11 18:09                             ` John Cowan
  0 siblings, 1 reply; 91+ messages in thread
From: Jon Forrest @ 2021-02-11 17:34 UTC (permalink / raw)
  To: tuhs



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

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

* Re: [TUHS] troff was not so widely usable
  2021-02-11 17:34                           ` Jon Forrest
@ 2021-02-11 18:09                             ` John Cowan
  2021-02-11 18:43                               ` Rich Morin
  0 siblings, 1 reply; 91+ messages in thread
From: John Cowan @ 2021-02-11 18:09 UTC (permalink / raw)
  To: Jon Forrest; +Cc: TUHS main list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable
  2021-02-11 18:09                             ` John Cowan
@ 2021-02-11 18:43                               ` Rich Morin
  0 siblings, 0 replies; 91+ messages in thread
From: Rich Morin @ 2021-02-11 18:43 UTC (permalink / raw)
  To: TUHS main list

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


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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11 16:55                       ` Ron Natalie
@ 2021-02-11 20:27                         ` John Cowan
  0 siblings, 0 replies; 91+ messages in thread
From: John Cowan @ 2021-02-11 20:27 UTC (permalink / raw)
  To: Ron Natalie; +Cc: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-10 22:05         ` Clem Cole
@ 2021-02-11 21:58           ` Greg A. Woods
  2021-02-12  5:22             ` George Michaelson
  2021-02-12 22:13             ` Dave Horsfall
  0 siblings, 2 replies; 91+ messages in thread
From: Greg A. Woods @ 2021-02-11 21:58 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- 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 --]

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11 21:58           ` Greg A. Woods
@ 2021-02-12  5:22             ` George Michaelson
  2021-02-12 22:13             ` Dave Horsfall
  1 sibling, 0 replies; 91+ messages in thread
From: George Michaelson @ 2021-02-12  5:22 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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>

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-11 21:58           ` Greg A. Woods
  2021-02-12  5:22             ` George Michaelson
@ 2021-02-12 22:13             ` Dave Horsfall
  2021-02-12 22:18               ` Ron Natalie
  1 sibling, 1 reply; 91+ messages in thread
From: Dave Horsfall @ 2021-02-12 22:13 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

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

* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
  2021-02-12 22:13             ` Dave Horsfall
@ 2021-02-12 22:18               ` Ron Natalie
  0 siblings, 0 replies; 91+ messages in thread
From: Ron Natalie @ 2021-02-12 22:18 UTC (permalink / raw)
  To: Dave Horsfall, The Eunuchs Hysterical Society

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


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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04 13:22                     ` Tyler Adams
@ 2020-12-04 13:25                       ` Niklas Karlsson
  0 siblings, 0 replies; 91+ messages in thread
From: Niklas Karlsson @ 2020-12-04 13:25 UTC (permalink / raw)
  To: Tyler Adams; +Cc: The Eunuchs Hysterical Society

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

Fair enough, and I guess it gets messy trying to remember all of the odd
exceptions.

Niklas

Den fre 4 dec. 2020 kl 14:23 skrev Tyler Adams <coppero1237@gmail.com>:

> Not always
>
> $ cat a | while read line; do echo $line; done
> #!/usr/bin/env bash
>
> PUPPETEER_PRODUCT=firefox npm install -g md-to-pdf
>
> $ < a while read line; do echo $line; done
> -bash: syntax error near unexpected token `do'
>
>
>  Tyler
>
>
> On Fri, Dec 4, 2020 at 3:17 PM Niklas Karlsson <nikke.karlsson@gmail.com>
> wrote:
>
>> < file grep foo works.
>>
>> Niklas
>>
>> Den fre 4 dec. 2020 kl 14:16 skrev Tyler Adams <coppero1237@gmail.com>:
>>
>>> I find cat file | grep foo simpler because it reads Left to Right.
>>>
>>>  Tyler
>>>
>>>
>>> On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela <akosela@andykosela.com>
>>> wrote:
>>>
>>>> On 12/4/20, arnold@skeeve.com <arnold@skeeve.com> wrote:
>>>> > Dan Cross <crossd@gmail.com> wrote:
>>>> >
>>>> >> This has always struck me as particularly elegant in scripts.
>>>> Consider:
>>>> >>
>>>> >>     cat "$@" | whatever
>>>> >>
>>>> >> (Or you may prefer `cat $* | whatever`)
>>>> >>
>>>> >> Now one's script can take any number of file arguments or stdin,
>>>> even if
>>>> >> the filter does not.
>>>> >
>>>> > I think Dan has hit the heart of the matter. People are used to using
>>>> > cat for multiple files to start pumping data down a pipeline, so they
>>>> > continue to do so even when there's only one file.
>>>> >
>>>>
>>>> The classic example is:
>>>>
>>>>   $ cat file | grep foo
>>>>
>>>> instead of the simpler:
>>>>
>>>>   $ grep foo file
>>>>
>>>> It appears cat(1) and pipe(7) are deeply ingrained in people's brains.
>>>>
>>>> --Andy
>>>>
>>>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04 13:17                   ` Niklas Karlsson
@ 2020-12-04 13:22                     ` Tyler Adams
  2020-12-04 13:25                       ` Niklas Karlsson
  0 siblings, 1 reply; 91+ messages in thread
From: Tyler Adams @ 2020-12-04 13:22 UTC (permalink / raw)
  To: Niklas Karlsson; +Cc: The Eunuchs Hysterical Society

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

Not always

$ cat a | while read line; do echo $line; done
#!/usr/bin/env bash

PUPPETEER_PRODUCT=firefox npm install -g md-to-pdf

$ < a while read line; do echo $line; done
-bash: syntax error near unexpected token `do'


 Tyler


On Fri, Dec 4, 2020 at 3:17 PM Niklas Karlsson <nikke.karlsson@gmail.com>
wrote:

> < file grep foo works.
>
> Niklas
>
> Den fre 4 dec. 2020 kl 14:16 skrev Tyler Adams <coppero1237@gmail.com>:
>
>> I find cat file | grep foo simpler because it reads Left to Right.
>>
>>  Tyler
>>
>>
>> On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela <akosela@andykosela.com>
>> wrote:
>>
>>> On 12/4/20, arnold@skeeve.com <arnold@skeeve.com> wrote:
>>> > Dan Cross <crossd@gmail.com> wrote:
>>> >
>>> >> This has always struck me as particularly elegant in scripts.
>>> Consider:
>>> >>
>>> >>     cat "$@" | whatever
>>> >>
>>> >> (Or you may prefer `cat $* | whatever`)
>>> >>
>>> >> Now one's script can take any number of file arguments or stdin, even
>>> if
>>> >> the filter does not.
>>> >
>>> > I think Dan has hit the heart of the matter. People are used to using
>>> > cat for multiple files to start pumping data down a pipeline, so they
>>> > continue to do so even when there's only one file.
>>> >
>>>
>>> The classic example is:
>>>
>>>   $ cat file | grep foo
>>>
>>> instead of the simpler:
>>>
>>>   $ grep foo file
>>>
>>> It appears cat(1) and pipe(7) are deeply ingrained in people's brains.
>>>
>>> --Andy
>>>
>>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04 13:14                 ` Tyler Adams
@ 2020-12-04 13:17                   ` Niklas Karlsson
  2020-12-04 13:22                     ` Tyler Adams
  0 siblings, 1 reply; 91+ messages in thread
From: Niklas Karlsson @ 2020-12-04 13:17 UTC (permalink / raw)
  To: Tyler Adams; +Cc: The Eunuchs Hysterical Society

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

< file grep foo works.

Niklas

Den fre 4 dec. 2020 kl 14:16 skrev Tyler Adams <coppero1237@gmail.com>:

> I find cat file | grep foo simpler because it reads Left to Right.
>
>  Tyler
>
>
> On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela <akosela@andykosela.com> wrote:
>
>> On 12/4/20, arnold@skeeve.com <arnold@skeeve.com> wrote:
>> > Dan Cross <crossd@gmail.com> wrote:
>> >
>> >> This has always struck me as particularly elegant in scripts. Consider:
>> >>
>> >>     cat "$@" | whatever
>> >>
>> >> (Or you may prefer `cat $* | whatever`)
>> >>
>> >> Now one's script can take any number of file arguments or stdin, even
>> if
>> >> the filter does not.
>> >
>> > I think Dan has hit the heart of the matter. People are used to using
>> > cat for multiple files to start pumping data down a pipeline, so they
>> > continue to do so even when there's only one file.
>> >
>>
>> The classic example is:
>>
>>   $ cat file | grep foo
>>
>> instead of the simpler:
>>
>>   $ grep foo file
>>
>> It appears cat(1) and pipe(7) are deeply ingrained in people's brains.
>>
>> --Andy
>>
>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04 11:33               ` Andy Kosela
@ 2020-12-04 13:14                 ` Tyler Adams
  2020-12-04 13:17                   ` Niklas Karlsson
  0 siblings, 1 reply; 91+ messages in thread
From: Tyler Adams @ 2020-12-04 13:14 UTC (permalink / raw)
  To: Andy Kosela; +Cc: The Eunuchs Hysterical Society

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

I find cat file | grep foo simpler because it reads Left to Right.

 Tyler


On Fri, Dec 4, 2020 at 1:34 PM Andy Kosela <akosela@andykosela.com> wrote:

> On 12/4/20, arnold@skeeve.com <arnold@skeeve.com> wrote:
> > Dan Cross <crossd@gmail.com> wrote:
> >
> >> This has always struck me as particularly elegant in scripts. Consider:
> >>
> >>     cat "$@" | whatever
> >>
> >> (Or you may prefer `cat $* | whatever`)
> >>
> >> Now one's script can take any number of file arguments or stdin, even if
> >> the filter does not.
> >
> > I think Dan has hit the heart of the matter. People are used to using
> > cat for multiple files to start pumping data down a pipeline, so they
> > continue to do so even when there's only one file.
> >
>
> The classic example is:
>
>   $ cat file | grep foo
>
> instead of the simpler:
>
>   $ grep foo file
>
> It appears cat(1) and pipe(7) are deeply ingrained in people's brains.
>
> --Andy
>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  9:27             ` arnold
@ 2020-12-04 11:33               ` Andy Kosela
  2020-12-04 13:14                 ` Tyler Adams
  0 siblings, 1 reply; 91+ messages in thread
From: Andy Kosela @ 2020-12-04 11:33 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

On 12/4/20, arnold@skeeve.com <arnold@skeeve.com> wrote:
> Dan Cross <crossd@gmail.com> wrote:
>
>> This has always struck me as particularly elegant in scripts. Consider:
>>
>>     cat "$@" | whatever
>>
>> (Or you may prefer `cat $* | whatever`)
>>
>> Now one's script can take any number of file arguments or stdin, even if
>> the filter does not.
>
> I think Dan has hit the heart of the matter. People are used to using
> cat for multiple files to start pumping data down a pipeline, so they
> continue to do so even when there's only one file.
>

The classic example is:

  $ cat file | grep foo

instead of the simpler:

  $ grep foo file

It appears cat(1) and pipe(7) are deeply ingrained in people's brains.

--Andy

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  1:25           ` Dan Cross
@ 2020-12-04  9:27             ` arnold
  2020-12-04 11:33               ` Andy Kosela
  0 siblings, 1 reply; 91+ messages in thread
From: arnold @ 2020-12-04  9:27 UTC (permalink / raw)
  To: robpike, crossd; +Cc: tuhs

Dan Cross <crossd@gmail.com> wrote:

> This has always struck me as particularly elegant in scripts. Consider:
>
>     cat "$@" | whatever
>
> (Or you may prefer `cat $* | whatever`)
>
> Now one's script can take any number of file arguments or stdin, even if
> the filter does not.

I think Dan has hit the heart of the matter. People are used to using
cat for multiple files to start pumping data down a pipeline, so they
continue to do so even when there's only one file.

Arnold

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  0:43         ` Rob Pike
  2020-12-04  0:48           ` Larry McVoy
@ 2020-12-04  1:25           ` Dan Cross
  2020-12-04  9:27             ` arnold
  1 sibling, 1 reply; 91+ messages in thread
From: Dan Cross @ 2020-12-04  1:25 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

On Thu, Dec 3, 2020 at 7:44 PM Rob Pike <robpike@gmail.com> wrote:

> I've long been fascinated by the prevalence of
>
>    cat file | process
>
> and think of it as a sort of triumph of the model. Pipes are more natural
> than redirection as a human interface.
>

This has always struck me as particularly elegant in scripts. Consider:

    cat "$@" | whatever

(Or you may prefer `cat $* | whatever`)

Now one's script can take any number of file arguments or stdin, even if
the filter does not.

        - Dan C.

On Fri, Dec 4, 2020 at 11:30 AM Dave Horsfall <dave@horsfall.org> wrote:
>
>> On Thu, 3 Dec 2020, Larry McVoy wrote:
>>
>> > Wasn't there a version that was
>> >
>> >       cat whatever ^ wc -l
>>
>> Sort of pipe-related, but one thing that really gets my goat is the
>> inefficient redundancy in "cat file | process" when "process < file" will
>> suffice (and I'll bet that I'm not alone).
>>
>> And yes, "^" preceded "|" for reasons discussed later in this thread.
>>
>> -- Dave
>>
>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  1:10         ` Bakul Shah
@ 2020-12-04  1:17           ` George Michaelson
  0 siblings, 0 replies; 91+ messages in thread
From: George Michaelson @ 2020-12-04  1:17 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society

ggm@ggm-802382 ~ %  h 1-|wc -l; h 1-|grep '<' | wc -l; h 1-|grep '>' |
wc -l; h 1-|grep '|'|wc -l
    1005
      34
      14
      91
ggm@ggm-802382 ~ %

On Fri, Dec 4, 2020 at 11:11 AM Bakul Shah <bakul@iitbombay.org> wrote:
>
> On Dec 3, 2020, at 4:29 PM, Dave Horsfall <dave@horsfall.org> wrote:
> >
> > On Thu, 3 Dec 2020, Larry McVoy wrote:
> >
> >> Wasn't there a version that was
> >>
> >>      cat whatever ^ wc -l
> >
> > Sort of pipe-related, but one thing that really gets my goat is the inefficient redundancy in "cat file | process" when "process < file" will suffice (and I'll bet that I'm not alone).
>
> Checking command history in zsh:
> $ h 1-|wc -l; h 1-|grep '<' | wc -l; h 1-|grep '>' | wc -l; h 1-|grep '|'|wc -l
>    10009
>      125
>      225
>      878
>
> So it appears I used < ~1%, > ~2% and | ~9% of the command lines!
> I bet others will something similar.

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  0:29       ` Dave Horsfall
  2020-12-04  0:43         ` Rob Pike
  2020-12-04  0:45         ` George Michaelson
@ 2020-12-04  1:10         ` Bakul Shah
  2020-12-04  1:17           ` George Michaelson
  2 siblings, 1 reply; 91+ messages in thread
From: Bakul Shah @ 2020-12-04  1:10 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Dec 3, 2020, at 4:29 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Thu, 3 Dec 2020, Larry McVoy wrote:
> 
>> Wasn't there a version that was
>> 
>> 	cat whatever ^ wc -l
> 
> Sort of pipe-related, but one thing that really gets my goat is the inefficient redundancy in "cat file | process" when "process < file" will suffice (and I'll bet that I'm not alone).

Checking command history in zsh:
$ h 1-|wc -l; h 1-|grep '<' | wc -l; h 1-|grep '>' | wc -l; h 1-|grep '|'|wc -l
   10009
     125
     225
     878

So it appears I used < ~1%, > ~2% and | ~9% of the command lines!
I bet others will something similar.

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  0:43         ` Rob Pike
@ 2020-12-04  0:48           ` Larry McVoy
  2020-12-04  1:25           ` Dan Cross
  1 sibling, 0 replies; 91+ messages in thread
From: Larry McVoy @ 2020-12-04  0:48 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

I should have done

	cat file file2 file3 ^ wc -l

since the redirect works with only one file.

On Fri, Dec 04, 2020 at 11:43:52AM +1100, Rob Pike wrote:
> I've long been fascinated by the prevalence of
> 
>    cat file | process
> 
> and think of it as a sort of triumph of the model. Pipes are more natural
> than redirection as a human interface.
> 
> -rob
> 
> 
> On Fri, Dec 4, 2020 at 11:30 AM Dave Horsfall <dave@horsfall.org> wrote:
> 
> > On Thu, 3 Dec 2020, Larry McVoy wrote:
> >
> > > Wasn't there a version that was
> > >
> > >       cat whatever ^ wc -l
> >
> > Sort of pipe-related, but one thing that really gets my goat is the
> > inefficient redundancy in "cat file | process" when "process < file" will
> > suffice (and I'll bet that I'm not alone).
> >
> > And yes, "^" preceded "|" for reasons discussed later in this thread.
> >
> > -- Dave
> >

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  0:29       ` Dave Horsfall
  2020-12-04  0:43         ` Rob Pike
@ 2020-12-04  0:45         ` George Michaelson
  2020-12-04  1:10         ` Bakul Shah
  2 siblings, 0 replies; 91+ messages in thread
From: George Michaelson @ 2020-12-04  0:45 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

I also get this, but there is a part of this which is about the
history of your command stream as a history of thinking.

cat file
<blurs past>

(sigh)

cat file | more

not more file. because you are heading to
cat file | cut -d, -f1,2 | real-job

yes, the cat is redundant. but syntactically it is like  (a b) + vs
plus(a,b) its not the functional order of the atoms for execution, its
how you "pronounce" the work you are doing inside your head..
expressed through your fingers.

The cost of the cat is really not big. the cost of re-framing your
command to  cmd < thing  is sometimes higher in brain cost. Brains are
expensive.

On Fri, Dec 4, 2020 at 10:30 AM Dave Horsfall <dave@horsfall.org> wrote:
>
> On Thu, 3 Dec 2020, Larry McVoy wrote:
>
> > Wasn't there a version that was
> >
> >       cat whatever ^ wc -l
>
> Sort of pipe-related, but one thing that really gets my goat is the
> inefficient redundancy in "cat file | process" when "process < file" will
> suffice (and I'll bet that I'm not alone).
>
> And yes, "^" preceded "|" for reasons discussed later in this thread.
>
> -- Dave

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-04  0:29       ` Dave Horsfall
@ 2020-12-04  0:43         ` Rob Pike
  2020-12-04  0:48           ` Larry McVoy
  2020-12-04  1:25           ` Dan Cross
  2020-12-04  0:45         ` George Michaelson
  2020-12-04  1:10         ` Bakul Shah
  2 siblings, 2 replies; 91+ messages in thread
From: Rob Pike @ 2020-12-04  0:43 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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

I've long been fascinated by the prevalence of

   cat file | process

and think of it as a sort of triumph of the model. Pipes are more natural
than redirection as a human interface.

-rob


On Fri, Dec 4, 2020 at 11:30 AM Dave Horsfall <dave@horsfall.org> wrote:

> On Thu, 3 Dec 2020, Larry McVoy wrote:
>
> > Wasn't there a version that was
> >
> >       cat whatever ^ wc -l
>
> Sort of pipe-related, but one thing that really gets my goat is the
> inefficient redundancy in "cat file | process" when "process < file" will
> suffice (and I'll bet that I'm not alone).
>
> And yes, "^" preceded "|" for reasons discussed later in this thread.
>
> -- Dave
>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-03 20:43     ` Larry McVoy
                         ` (2 preceding siblings ...)
  2020-12-03 21:12       ` Clem Cole
@ 2020-12-04  0:29       ` Dave Horsfall
  2020-12-04  0:43         ` Rob Pike
                           ` (2 more replies)
  3 siblings, 3 replies; 91+ messages in thread
From: Dave Horsfall @ 2020-12-04  0:29 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Thu, 3 Dec 2020, Larry McVoy wrote:

> Wasn't there a version that was
>
> 	cat whatever ^ wc -l

Sort of pipe-related, but one thing that really gets my goat is the 
inefficient redundancy in "cat file | process" when "process < file" will 
suffice (and I'll bet that I'm not alone).

And yes, "^" preceded "|" for reasons discussed later in this thread.

-- Dave

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-03 20:43     ` Larry McVoy
  2020-12-03 20:56       ` Ralph Corderoy
  2020-12-03 21:01       ` Ben Walton
@ 2020-12-03 21:12       ` Clem Cole
  2020-12-04  0:29       ` Dave Horsfall
  3 siblings, 0 replies; 91+ messages in thread
From: Clem Cole @ 2020-12-03 21:12 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

Yup early shell's equated ^ and |

The problem was while the Model - 33,  post 1965 could print a vertical
bar, as note 2 of page three of teletypes document: "33 Keyboard" General
Description and Principles of Operations" ISS 4, Section 574-121-100TC
(Issue 4, June 1974), the keyboard could not generate it.

On Thu, Dec 3, 2020 at 3:43 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Thu, Dec 03, 2020 at 09:37:17PM +0100, Niklas Karlsson wrote:
> > Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy <
> > m.douglas.mcilroy@dartmouth.edu>:
> >
> > > There's a back story. The paper appears in the proceedings  of a
> > > conference held in London in 1973, a few months after the advent of
> > > pipes. While preparing the presentation, Ken was inspired to invent
> > > and install the pipe operator. His talk wouldn't have been nearly as
> > > compelling had it been expressed in the original pipeline syntax (for
> > > which I take the blame).
> > >
> >
> > Now I'm curious. Is there anywhere I can read about the original pipeline
> > syntax? I tried searching a bit, but the only mention that was even
> vaguely
> > informative only stated that > was involved.
>
> Wasn't there a version that was
>
>         cat whatever ^ wc -l
>
> ?
>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-03 20:43     ` Larry McVoy
  2020-12-03 20:56       ` Ralph Corderoy
@ 2020-12-03 21:01       ` Ben Walton
  2020-12-03 21:12       ` Clem Cole
  2020-12-04  0:29       ` Dave Horsfall
  3 siblings, 0 replies; 91+ messages in thread
From: Ben Walton @ 2020-12-03 21:01 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

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

On Thu 3 Dec 2020, 20:43 Larry McVoy, <lm@mcvoy.com> wrote:

> On Thu, Dec 03, 2020 at 09:37:17PM +0100, Niklas Karlsson wrote:
> > Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy <
> > m.douglas.mcilroy@dartmouth.edu>:
> >
> > > There's a back story. The paper appears in the proceedings  of a
> > > conference held in London in 1973, a few months after the advent of
> > > pipes. While preparing the presentation, Ken was inspired to invent
> > > and install the pipe operator. His talk wouldn't have been nearly as
> > > compelling had it been expressed in the original pipeline syntax (for
> > > which I take the blame).
> > >
> >
> > Now I'm curious. Is there anywhere I can read about the original pipeline
> > syntax? I tried searching a bit, but the only mention that was even
> vaguely
> > informative only stated that > was involved.
>
> Wasn't there a version that was
>
>         cat whatever ^ wc -l
>
> ?
>

Yes, that's it. And you'll still find[1] that /bin/sh on (at least?)
Solaris honors that syntax. That's one reason why the git test suite fails
on Solaris without being pushed to use a modern shell implementation.

Thanks
-Ben

[1] At least up to Solaris 10. I've not used newer.

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-03 20:43     ` Larry McVoy
@ 2020-12-03 20:56       ` Ralph Corderoy
  2020-12-03 21:01       ` Ben Walton
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 91+ messages in thread
From: Ralph Corderoy @ 2020-12-03 20:56 UTC (permalink / raw)
  To: tuhs

Hi Larry,

> Wasn't there a version that was 
>
> 	cat whatever ^ wc -l

It existed for quite a while in Bourne's shell even when | came along
and was useful when the keyboard didn't have a | keycap or, more likely,
when it was a modern machine with the capability of mapping keys which
had a poor mapping with no | available.

-- 
Cheers, Ralph.

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-03 20:37   ` Niklas Karlsson
  2020-12-03 20:43     ` Larry McVoy
@ 2020-12-03 20:51     ` M Douglas McIlroy
  1 sibling, 0 replies; 91+ messages in thread
From: M Douglas McIlroy @ 2020-12-03 20:51 UTC (permalink / raw)
  To: Niklas Karlsson; +Cc: tuhs

https://archive.org/details/a_research_unix_reader  pp 29-30

On Thu, Dec 3, 2020 at 3:37 PM Niklas Karlsson <nikke.karlsson@gmail.com> wrote:
>
> Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu>:
>>
>> There's a back story. The paper appears in the proceedings  of a
>> conference held in London in 1973, a few months after the advent of
>> pipes. While preparing the presentation, Ken was inspired to invent
>> and install the pipe operator. His talk wouldn't have been nearly as
>> compelling had it been expressed in the original pipeline syntax (for
>> which I take the blame).
>
>
> Now I'm curious. Is there anywhere I can read about the original pipeline syntax? I tried searching a bit, but the only mention that was even vaguely informative only stated that > was involved.
>
> Thanks!
> Niklas

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-03 20:37   ` Niklas Karlsson
@ 2020-12-03 20:43     ` Larry McVoy
  2020-12-03 20:56       ` Ralph Corderoy
                         ` (3 more replies)
  2020-12-03 20:51     ` M Douglas McIlroy
  1 sibling, 4 replies; 91+ messages in thread
From: Larry McVoy @ 2020-12-03 20:43 UTC (permalink / raw)
  To: Niklas Karlsson; +Cc: tuhs

On Thu, Dec 03, 2020 at 09:37:17PM +0100, Niklas Karlsson wrote:
> Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy <
> m.douglas.mcilroy@dartmouth.edu>:
> 
> > There's a back story. The paper appears in the proceedings  of a
> > conference held in London in 1973, a few months after the advent of
> > pipes. While preparing the presentation, Ken was inspired to invent
> > and install the pipe operator. His talk wouldn't have been nearly as
> > compelling had it been expressed in the original pipeline syntax (for
> > which I take the blame).
> >
> 
> Now I'm curious. Is there anywhere I can read about the original pipeline
> syntax? I tried searching a bit, but the only mention that was even vaguely
> informative only stated that > was involved.

Wasn't there a version that was 

	cat whatever ^ wc -l

?

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-03 20:31 ` M Douglas McIlroy
@ 2020-12-03 20:37   ` Niklas Karlsson
  2020-12-03 20:43     ` Larry McVoy
  2020-12-03 20:51     ` M Douglas McIlroy
  0 siblings, 2 replies; 91+ messages in thread
From: Niklas Karlsson @ 2020-12-03 20:37 UTC (permalink / raw)
  To: M Douglas McIlroy; +Cc: tuhs

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

Den tors 3 dec. 2020 kl 21:32 skrev M Douglas McIlroy <
m.douglas.mcilroy@dartmouth.edu>:

> There's a back story. The paper appears in the proceedings  of a
> conference held in London in 1973, a few months after the advent of
> pipes. While preparing the presentation, Ken was inspired to invent
> and install the pipe operator. His talk wouldn't have been nearly as
> compelling had it been expressed in the original pipeline syntax (for
> which I take the blame).
>

Now I'm curious. Is there anywhere I can read about the original pipeline
syntax? I tried searching a bit, but the only mention that was even vaguely
informative only stated that > was involved.

Thanks!
Niklas

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

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

* Re: [TUHS] The UNIX Command Language (1976)
       [not found] <CAKH6PiWA2uN4m0AGp7VRJTQ6XXDLJQweHoHjx2wN=zQYs1onpA@mail.gmail.com>
@ 2020-12-03 20:31 ` M Douglas McIlroy
  2020-12-03 20:37   ` Niklas Karlsson
  0 siblings, 1 reply; 91+ messages in thread
From: M Douglas McIlroy @ 2020-12-03 20:31 UTC (permalink / raw)
  To: tuhs

There's a back story. The paper appears in the proceedings  of a
conference held in London in 1973, a few months after the advent of
pipes. While preparing the presentation, Ken was inspired to invent
and install the pipe operator. His talk wouldn't have been nearly as
compelling had it been expressed in the original pipeline syntax (for
which I take the blame).

References to eqn (v5), bc (v6), and ratfor (v7) obviously postdate
the London conference. Ken must have edited--or re-created--the
transcript for the proceedings sometime after v6 (May, 1975).

Bibliographic citations are missing. Can they be resurrected?
Reference 137, about Unix itself, probably refers to a
presentation by Ken and Dennis at SOSP in January1973. Alas, only an
abstract of the talk appears in the conference proceedings. But the
abstract does contain the potent and often-repeated sentence, "It
offers a number of features seldom found even in larger operating
systems, including ... inter-process IO ..." The talk--in Yorktown
Heights--was memorable, and so was a ride to the same place in Ken's
'vette. (I can't recall whether the two happened on the same
occasion.)

Given that the talk at SOSP preceded the talk in London, and that the
Unix manual was widely distributed by (1976) when the revised London
talk was printed, the claim that "The Unix command language" was the
first publication of Unix seems hyperbolic. In no way, though, does
this detract from the inherent interest of the paper.

Doug

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-02  1:06   ` Adam Thornton
@ 2020-12-02 17:02     ` John Cowan
  0 siblings, 0 replies; 91+ messages in thread
From: John Cowan @ 2020-12-02 17:02 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

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

On Tue, Dec 1, 2020 at 8:06 PM Adam Thornton <athornton@gmail.com> wrote:

Pretty sure I would pass ALL the members of the list on the street and fail
> to recognize them.  Yes, even the famous ones.
>

I can pass anyone on the street and fail to recognize them (google
"prosopagnosia" or "face blindness").

> Also, "Fight Club" is not a crap movie and I will fight you over that.
>

The first rule of Fish Club is that whales are not fish.
The second rule of Fish Club is that lungfish are not fish either.

The first rule of Linguist Club is to explain who belongs to Linguist Club.

The first rule of Tautology Club is the first rule of Tautology Club.



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: 3041 bytes --]

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-02  0:31 ` George Michaelson
@ 2020-12-02  1:06   ` Adam Thornton
  2020-12-02 17:02     ` John Cowan
  0 siblings, 1 reply; 91+ messages in thread
From: Adam Thornton @ 2020-12-02  1:06 UTC (permalink / raw)
  To: George Michaelson; +Cc: The Eunuchs Hysterical Society

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

Pretty sure I would pass ALL the members of the list on the street and fail
to recognize them.  Yes, even the famous ones.

Also, "Fight Club" is not a crap movie and I will fight you over that.

Adam

On Tue, Dec 1, 2020 at 5:32 PM George Michaelson <ggm@algebras.org> wrote:

> I don't normally like referring to "fight club" because its a crap
> movie. But "we don't talk about fight club" is a really useful rule.
>
> If you name call people on a list too much, they don't want to be on
> the list. It's not a place to collect gold stamps, or rare birds.
>
> I suspect I'd pass half the members of the list on the street and fail
> to recognize them. I very much hope this is reciprocated.
>
> cheers
>
> -G
>

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01  3:13 Norman Wilson
@ 2020-12-02  0:31 ` George Michaelson
  2020-12-02  1:06   ` Adam Thornton
  0 siblings, 1 reply; 91+ messages in thread
From: George Michaelson @ 2020-12-02  0:31 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

I don't normally like referring to "fight club" because its a crap
movie. But "we don't talk about fight club" is a really useful rule.

If you name call people on a list too much, they don't want to be on
the list. It's not a place to collect gold stamps, or rare birds.

I suspect I'd pass half the members of the list on the street and fail
to recognize them. I very much hope this is reciprocated.

cheers

-G

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

* Re: [TUHS] The UNIX Command Language (1976)
@ 2020-12-01  3:13 Norman Wilson
  2020-12-02  0:31 ` George Michaelson
  0 siblings, 1 reply; 91+ messages in thread
From: Norman Wilson @ 2020-12-01  3:13 UTC (permalink / raw)
  To: tuhs

  I'm also forwarding this message that arrived in my mailbox. Is this 
  **THE** Ken Thompson?

Yes, that's the real Ken.  Those who have communicated
with him in the past (and didn't get a direct note as
some of us did) should notice the new e-mail address,
kenbob@gmail.com.

Norman Wilson
Toronto ON

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01  0:21   ` Dave Horsfall
@ 2020-12-01  2:23     ` Larry McVoy
  0 siblings, 0 replies; 91+ messages in thread
From: Larry McVoy @ 2020-12-01  2:23 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

He is.  So is Rob Pike, Doug, Steve Johnson, Steve Bourne (I got him here)
pretty much all of the remaining Bell Lab luminaries except for bwk.
I've tried to twist his arm, he's remained a hard nut to crack.  I think
the list, and he, would love it if he were here.  So long as we keep it
on point and move stuff like tputs to COFF right away.

I suspect all of them don't want a big deal made about them, my guess
is they are here to talk about Unix.  Just my opinion.

On Tue, Dec 01, 2020 at 11:21:51AM +1100, Dave Horsfall wrote:
> On Mon, 30 Nov 2020, Joachim via TUHS wrote:
> 
> >I'm also forwarding this message that arrived in my mailbox. Is this
> >**THE** Ken Thompson?
> 
> I think he's on this list...
> 
> -- Dave

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

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

* Re: [TUHS] The UNIX Command Language (1976)
  2020-12-01  0:00 ` Joachim via TUHS
@ 2020-12-01  0:21   ` Dave Horsfall
  2020-12-01  2:23     ` Larry McVoy
  0 siblings, 1 reply; 91+ messages in thread
From: Dave Horsfall @ 2020-12-01  0:21 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 30 Nov 2020, Joachim via TUHS wrote:

> I'm also forwarding this message that arrived in my mailbox. Is this 
> **THE** Ken Thompson?

I think he's on this list...

-- Dave

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

* Re: [TUHS] The UNIX Command Language (1976)
       [not found] <CAMP=X_mO9oawUpHGOvgVtwVTgcmvdXAc5vrE_+s3d2NsH+1HgA@mail.gmail.com>
@ 2020-12-01  0:00 ` Joachim via TUHS
  2020-12-01  0:21   ` Dave Horsfall
  0 siblings, 1 reply; 91+ messages in thread
From: Joachim via TUHS @ 2020-12-01  0:00 UTC (permalink / raw)
  To: TUHS main list

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

I'm also forwarding this message that arrived in my mailbox. Is this 
**THE** Ken Thompson?

Joachim


-------- Forwarded Message --------
Subject: 	Re: [TUHS] The UNIX Command Language (1976)
Date: 	Sun, 29 Nov 2020 21:47:16 -0800
From: 	Ken Thompson <kenbob@gmail.com>
To: 	Joachim <j@tllds.com>




yes. the unix manual was published before that,
but i dont think it was released that early. it had
a manual page on the shell.

this paper might be the first paper ever released
outside bell labs.



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

    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: 3458 bytes --]

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

end of thread, other threads:[~2021-02-12 22:18 UTC | newest]

Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-30  3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS
2020-11-30  8:30 ` Thomas Paulsen
2020-11-30 13:36 ` Brantley Coile
2020-11-30 15:12   ` Tom Ivar Helbekkmo via TUHS
2020-11-30 15:52 ` Clem Cole
2020-11-30 16:25   ` Dan Cross
2020-11-30 16:38     ` Warner Losh
2020-11-30 16:41       ` Dan Cross
2020-11-30 16:37   ` Larry McVoy
2020-11-30 16:54     ` Clem Cole
2020-11-30 18:13       ` Theodore Y. Ts'o
2020-11-30 18:25       ` John Cowan
2020-11-30 18:37         ` Clem Cole
2020-11-30 20:11           ` arnold
2020-11-30 21:49             ` Will Senn
2020-12-01  2:55             ` Jon Steinhart
2020-11-30 18:46         ` Nemo Nusquam
2021-02-10 20:48       ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods
2021-02-10 21:44         ` Larry McVoy
2021-02-10 22:05         ` Clem Cole
2021-02-11 21:58           ` Greg A. Woods
2021-02-12  5:22             ` George Michaelson
2021-02-12 22:13             ` Dave Horsfall
2021-02-12 22:18               ` Ron Natalie
2021-02-10 22:36         ` Jon Steinhart
2021-02-10 23:05           ` George Michaelson
2021-02-11  0:27             ` Ron Natalie
2021-02-11  0:36               ` Larry McVoy
2021-02-11  1:53               ` Clem Cole
2021-02-11  1:59                 ` Richard Salz
2021-02-11  2:04                   ` George Michaelson
2021-02-11  2:44                     ` Richard Salz
2021-02-11  3:02                       ` Steve Nickolas
2021-02-11  4:07                         ` Toby Thain
2021-02-11 16:55                       ` Ron Natalie
2021-02-11 20:27                         ` John Cowan
2021-02-11  2:30                 ` [TUHS] troff was not so widely usable Mary Ann Horton
2021-02-11  2:52                   ` Larry McVoy
2021-02-11  6:42                     ` Andrew Hume
2021-02-11  7:12                       ` Rob Pike
2021-02-11 13:06                         ` John Gilmore
2021-02-11 17:34                           ` Jon Forrest
2021-02-11 18:09                             ` John Cowan
2021-02-11 18:43                               ` Rich Morin
2020-12-01  3:59 ` [TUHS] The UNIX Command Language (1976) jason-tuhs
2020-12-01  4:03   ` Jon Steinhart
2020-12-01  9:27   ` Steve Nickolas
2020-12-01 15:09   ` Jim Capp
2020-12-01 15:35     ` Toby Thain
2020-12-01 15:38     ` arnold
2020-12-01 16:24       ` Warner Losh
2020-12-01 16:39         ` arnold
2020-12-01 20:13           ` Rob Pike
2020-12-02  7:08             ` arnold
2020-12-02  7:29               ` Rob Pike
2020-12-01 20:20           ` Steffen Nurpmeso
2020-12-01 20:39             ` Bakul Shah
2020-12-01 21:24               ` Dan Cross
2020-12-01 23:44                 ` John Cowan
2020-12-12 19:50           ` scj
2020-12-01 16:47         ` Larry McVoy
2020-12-01 20:13     ` Dave Horsfall
2020-12-01 20:49       ` John Cowan
2020-12-01 16:04 ` Tyler Adams
     [not found] <CAMP=X_mO9oawUpHGOvgVtwVTgcmvdXAc5vrE_+s3d2NsH+1HgA@mail.gmail.com>
2020-12-01  0:00 ` Joachim via TUHS
2020-12-01  0:21   ` Dave Horsfall
2020-12-01  2:23     ` Larry McVoy
2020-12-01  3:13 Norman Wilson
2020-12-02  0:31 ` George Michaelson
2020-12-02  1:06   ` Adam Thornton
2020-12-02 17:02     ` John Cowan
     [not found] <CAKH6PiWA2uN4m0AGp7VRJTQ6XXDLJQweHoHjx2wN=zQYs1onpA@mail.gmail.com>
2020-12-03 20:31 ` M Douglas McIlroy
2020-12-03 20:37   ` Niklas Karlsson
2020-12-03 20:43     ` Larry McVoy
2020-12-03 20:56       ` Ralph Corderoy
2020-12-03 21:01       ` Ben Walton
2020-12-03 21:12       ` Clem Cole
2020-12-04  0:29       ` Dave Horsfall
2020-12-04  0:43         ` Rob Pike
2020-12-04  0:48           ` Larry McVoy
2020-12-04  1:25           ` Dan Cross
2020-12-04  9:27             ` arnold
2020-12-04 11:33               ` Andy Kosela
2020-12-04 13:14                 ` Tyler Adams
2020-12-04 13:17                   ` Niklas Karlsson
2020-12-04 13:22                     ` Tyler Adams
2020-12-04 13:25                       ` Niklas Karlsson
2020-12-04  0:45         ` George Michaelson
2020-12-04  1:10         ` Bakul Shah
2020-12-04  1:17           ` George Michaelson
2020-12-03 20:51     ` M Douglas McIlroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).