The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] v7 source code for sh
@ 2022-02-19 17:44 Bakul Shah
  2022-02-19 18:44 ` Rob Pike
  0 siblings, 1 reply; 30+ messages in thread
From: Bakul Shah @ 2022-02-19 17:44 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

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

On Feb 19, 2022, at 8:11 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas <usotsuki@buric.co> wrote:
>> Apparently Bourne was heavily into ALGOL, 
> That's sort of an understatement.  I believe that when he was at Cambridge, he was one of the people that helped to take the Algol-X proposal and turned it into the Algol-68 definition. I also believe he worked on their famous implementation of same.

Some of you may be interested in this “A history of Algol68” paper:
https://dl.acm.org/doi/pdf/10.1145/234286.1057810
The author, Charles H Lindsey, still occasionally posts on comp.lang.misc
about Algol68. Among other things Bourne was a coauthor of Algol68C,
a portable implementation of Algol68.

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 17:44 [TUHS] v7 source code for sh Bakul Shah
@ 2022-02-19 18:44 ` Rob Pike
  2022-02-19 19:29   ` Clem Cole
  2022-02-19 22:39   ` John Cowan
  0 siblings, 2 replies; 30+ messages in thread
From: Rob Pike @ 2022-02-19 18:44 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

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

I undid all the macros for the v8 shell, with Steve's blessing, before
doing the key work on that shell. But no one outside cared about any of the
research Unixes after v7, sad though that is to admit, so his macros and
griping about them lingered on in the world.

I did the same to adb, which turned out to have a really good debugger
hidden under a few serious bugs of its own, which I fixed.

-rob


On Sun, Feb 20, 2022 at 4:46 AM Bakul Shah <bakul@iitbombay.org> wrote:

> On Feb 19, 2022, at 8:11 AM, Clem Cole <clemc@ccc.com> wrote:
>
> 
> On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas <usotsuki@buric.co> wrote:
>
>> Apparently Bourne was heavily into ALGOL,
>>
> That's sort of an understatement.  I believe that when he was at
> Cambridge, he was one of the people that helped to take the Algol-X
> proposal and turned it into the Algol-68 definition. I also believe he
> worked on their famous implementation of same.
>
>
> Some of you may be interested in this “A history of Algol68” paper:
> https://dl.acm.org/doi/pdf/10.1145/234286.1057810
> The author, Charles H Lindsey, still occasionally posts on comp.lang.misc
> about Algol68. Among other things Bourne was a coauthor of Algol68C,
> a portable implementation of Algol68.
>

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 18:44 ` Rob Pike
@ 2022-02-19 19:29   ` Clem Cole
  2022-02-19 22:39   ` John Cowan
  1 sibling, 0 replies; 30+ messages in thread
From: Clem Cole @ 2022-02-19 19:29 UTC (permalink / raw)
  To: Rob Pike; +Cc: Bakul Shah, TUHS main list

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

On Sat, Feb 19, 2022 at 1:44 PM Rob Pike <robpike@gmail.com> wrote:

> I did the same to adb, which turned out to have a really good debugger
> hidden under a few serious bugs of its own, which I fixed.
>
Amen ... still my favorite.  A number of us fixed them too.   In fact, we
put it into the kernel as kdb in the Masscomp system.

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 18:44 ` Rob Pike
  2022-02-19 19:29   ` Clem Cole
@ 2022-02-19 22:39   ` John Cowan
  2022-02-19 23:11     ` Sven Mascheck
  1 sibling, 1 reply; 30+ messages in thread
From: John Cowan @ 2022-02-19 22:39 UTC (permalink / raw)
  To: Rob Pike; +Cc: Bakul Shah, TUHS main list

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

On Sat, Feb 19, 2022 at 1:45 PM Rob Pike <robpike@gmail.com> wrote:


> I undid all the macros for the v8 shell, with Steve's blessing, before
> doing the key work on that shell. But no one outside cared about any of the
> research Unixes after v7,
>

Lots of us would have loved to care about them and were sad that we
couldn't until they were open sourced much later.

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 22:39   ` John Cowan
@ 2022-02-19 23:11     ` Sven Mascheck
  2022-02-19 23:34       ` Rob Pike
                         ` (2 more replies)
  0 siblings, 3 replies; 30+ messages in thread
From: Sven Mascheck @ 2022-02-19 23:11 UTC (permalink / raw)
  To: tuhs

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

On 19.02.2022 23:39, John Cowan wrote:
> On Sat, Feb 19, 2022 at 1:45 PM Rob Pike <robpike@gmail.com> wrote:
>
>     I undid all the macros for the v8 shell, with Steve's blessing,
>     before doing the key work on that shell. But no one outside cared
>     about any of the research Unixes after v7,
>
>
> Lots of us would have loved to care about them and were sad that we 
> couldn't until they were open sourced much later.

8th ed sh (about '84) brought quite a few changes and fixes. Just naming 
a few:
- environment variable HISTORY, pointing to a writable file, providing a 
history mechanism by means of "=(1)"
- type is replaced by whatis, which produces output that can be 
re-evaluated by the shell
- functions can be exported, in the same ways like variables

keyword history: I always imagined that the Bourne shell would have been 
in much wider use even nowadays, if only it had provided line editing 
and a history at some point. Why not? Even Kenneth Almquist released his 
SVR4-like reimplementation intentionally without history. All that might 
have been implemented more elegant directly in the terminal I/O instead 
of in every program? (that is, not in a MS-DOS-like way, where every 
program even needs its own pager).

I still wonder if it would be possible to properly provide line editing 
and history in the terminal I/O in general.

Sven

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 23:11     ` Sven Mascheck
@ 2022-02-19 23:34       ` Rob Pike
  2022-02-19 23:36       ` silas poulson
  2022-02-20 20:54       ` Chet Ramey
  2 siblings, 0 replies; 30+ messages in thread
From: Rob Pike @ 2022-02-19 23:34 UTC (permalink / raw)
  To: Sven Mascheck; +Cc: TUHS main list

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

Terminal editing was done in general on the Blit and follow-on systems.
That's primarily why the Research shells didn't do it.

But history (ha!) chose another path.

-rob


On Sun, Feb 20, 2022 at 10:20 AM Sven Mascheck <mascheck@in-ulm.de> wrote:

> On 19.02.2022 23:39, John Cowan wrote:
>
> On Sat, Feb 19, 2022 at 1:45 PM Rob Pike <robpike@gmail.com> wrote:
>
>
>> I undid all the macros for the v8 shell, with Steve's blessing, before
>> doing the key work on that shell. But no one outside cared about any of the
>> research Unixes after v7,
>>
>
> Lots of us would have loved to care about them and were sad that we
> couldn't until they were open sourced much later.
>
>
> 8th ed sh (about '84) brought quite a few changes and fixes. Just naming a
> few:
> - environment variable HISTORY, pointing to a writable file, providing a
> history mechanism by means of "=(1)"
> - type is replaced by whatis, which produces output that can be
> re-evaluated by the shell
> - functions can be exported, in the same ways like variables
>
> keyword history: I always imagined that the Bourne shell would have been
> in much wider use even nowadays, if only it had provided line editing and a
> history at some point. Why not? Even Kenneth Almquist released his
> SVR4-like reimplementation intentionally without history. All that might
> have been implemented more elegant directly in the terminal I/O instead of
> in every program? (that is, not in a MS-DOS-like way, where every program
> even needs its own pager).
>
> I still wonder if it would be possible to properly provide line editing
> and history in the terminal I/O in general.
>
> Sven
>

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 23:11     ` Sven Mascheck
  2022-02-19 23:34       ` Rob Pike
@ 2022-02-19 23:36       ` silas poulson
  2022-02-20 20:54       ` Chet Ramey
  2 siblings, 0 replies; 30+ messages in thread
From: silas poulson @ 2022-02-19 23:36 UTC (permalink / raw)
  To: Sven Mascheck; +Cc: tuhs

> On 19 Feb 2022, at 23:11, Sven Mascheck <mascheck@in-ulm.de> wrote:
> I still wonder if it would be possible to properly provide line editing and history in the terminal I/O in general.

Probably not quite what you mean, but enjoy Plan 9’s combination via acme of text executable wherever exists and can see what you’ve written and how it’s been changed.

Silas


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

* Re: [TUHS] v7 source code for sh
  2022-02-19 23:11     ` Sven Mascheck
  2022-02-19 23:34       ` Rob Pike
  2022-02-19 23:36       ` silas poulson
@ 2022-02-20 20:54       ` Chet Ramey
  2022-02-20 21:02         ` Larry McVoy
  2022-02-20 21:19         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  2 siblings, 2 replies; 30+ messages in thread
From: Chet Ramey @ 2022-02-20 20:54 UTC (permalink / raw)
  To: Sven Mascheck, tuhs

On 2/19/22 6:11 PM, Sven Mascheck wrote:

> keyword history: I always imagined that the Bourne shell would have been in 
> much wider use even nowadays, if only it had provided line editing and a 
> history at some point. Why not? 

I think it's that the people with the power to make it happen didn't view
it as an appropriate feature for the shell.

It was much easier to implement in the shell, both technically and
socially. Instead of having to convince kernel developers to implement and
maintain editing in the terminal driver (both emacs and vi modes, to boot),
it's easier for one person, maybe a few, to do a user-space implementation.
That's how it ended up in ksh, for instance.

Rob already talked about the Blit editing, which obviated the need to have
it in the shell.


> Even Kenneth Almquist released his 
> SVR4-like reimplementation intentionally without history.

Almquist released `atty' the same time as `ash', so he did at least provide
a way to do editing and history using ptys, in the same way that `rlwrap'
wraps readline.

But he decried its lack of "elegance," and described it as something that
"should be rewritten properly, with appropriate kernel support."


> All that might 
> have been implemented more elegant directly in the terminal I/O instead of 
> in every program? (that is, not in a MS-DOS-like way, where every program 
> even needs its own pager).

Elegant, maybe, but it never seemed to take off. There were a few different
implementations, but none was ever blessed as something officially
integrated into a widely-distributed kernel. (As I recall, Jon Payne, who
wrote JOVE while in high school (!), wrote one as a college course project.
I remember him describing it on Usenet back in the day. There were others.)

It always seemed like it would have been just the thing to implement as a
tty streams module, but research Unix went in a different direction.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

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

* Re: [TUHS] v7 source code for sh
  2022-02-20 20:54       ` Chet Ramey
@ 2022-02-20 21:02         ` Larry McVoy
  2022-02-20 21:19           ` Chet Ramey
  2022-02-20 21:19         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  1 sibling, 1 reply; 30+ messages in thread
From: Larry McVoy @ 2022-02-20 21:02 UTC (permalink / raw)
  To: Chet Ramey; +Cc: tuhs

On Sun, Feb 20, 2022 at 03:54:12PM -0500, Chet Ramey wrote:
> >All that might have been implemented more elegant directly in the terminal
> >I/O instead of in every program? (that is, not in a MS-DOS-like way, where
> >every program even needs its own pager).
> 
> Elegant, maybe, but it never seemed to take off. 
> 
> It always seemed like it would have been just the thing to implement as a
> tty streams module, but research Unix went in a different direction.

Not really.  You want history files, I have one for each tty.  Telling
the tty driver to write to this inode seems sort of weird.  I guess you
could make it work, but to me, this screams libc or libhistory or 
something like that.  I agree it shouldn't be in each app that wants
it but isn't that what libraries are for?

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

* Re: [TUHS] v7 source code for sh
  2022-02-20 20:54       ` Chet Ramey
  2022-02-20 21:02         ` Larry McVoy
@ 2022-02-20 21:19         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
  2022-02-20 22:39           ` Chet Ramey
  1 sibling, 1 reply; 30+ messages in thread
From: Lyndon Nerenberg (VE7TFX/VE6BBM) @ 2022-02-20 21:19 UTC (permalink / raw)
  To: chet.ramey; +Cc: tuhs

Chet Ramey writes:

> It always seemed like it would have been just the thing to implement as a
> tty streams module, but research Unix went in a different direction.

I'm really surprised nobody has implemented a basic readline as a
tty line discipline by now.  I was poking around the OpenBSD NMEA
line discipline code a few weeks ago and thinking it shouldn't be
that hard to do.

Did anyone think about doing this in the past? If yes, what made you
decide against doing it?  (Or a streams implementation, for that matter.)

--lyndon

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

* Re: [TUHS] v7 source code for sh
  2022-02-20 21:02         ` Larry McVoy
@ 2022-02-20 21:19           ` Chet Ramey
  0 siblings, 0 replies; 30+ messages in thread
From: Chet Ramey @ 2022-02-20 21:19 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

On 2/20/22 4:02 PM, Larry McVoy wrote:

>> It always seemed like it would have been just the thing to implement as a
>> tty streams module, but research Unix went in a different direction.
> 
> Not really.  You want history files, I have one for each tty.  Telling
> the tty driver to write to this inode seems sort of weird.  I guess you
> could make it work, but to me, this screams libc or libhistory or
> something like that. 

History maybe, but most folks seem to want editing more, and just that
incremental improvement would have made a difference.

> I agree it shouldn't be in each app that wants
> it but isn't that what libraries are for?

That's why readline is a library, with application-specific hooks 
available, and relies on something like rlwrap if you want to use editing
and history with an unmodified application.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

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

* Re: [TUHS] v7 source code for sh
  2022-02-20 21:19         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
@ 2022-02-20 22:39           ` Chet Ramey
  2022-02-21  1:01             ` Dan Cross
  0 siblings, 1 reply; 30+ messages in thread
From: Chet Ramey @ 2022-02-20 22:39 UTC (permalink / raw)
  To: Lyndon Nerenberg (VE7TFX/VE6BBM); +Cc: tuhs

On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> Chet Ramey writes:
> 
>> It always seemed like it would have been just the thing to implement as a
>> tty streams module, but research Unix went in a different direction.
> 
> I'm really surprised nobody has implemented a basic readline as a
> tty line discipline by now.  I was poking around the OpenBSD NMEA
> line discipline code a few weeks ago and thinking it shouldn't be
> that hard to do.

It's not that hard. The complexity is in how sophisticated you want to get
with redisplay and whether you want to allow user-specified key bindings.

> Did anyone think about doing this in the past? If yes, what made you
> decide against doing it?  (Or a streams implementation, for that matter.)

There have been several implementations (I never did one). I suspect that
the people who were in a position to integrate that functionality into
distributed kernels were not supportive, or the code didn't get to them
at the right time.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

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

* Re: [TUHS] v7 source code for sh
  2022-02-20 22:39           ` Chet Ramey
@ 2022-02-21  1:01             ` Dan Cross
  2022-02-22  4:54               ` Dan Stromberg
  0 siblings, 1 reply; 30+ messages in thread
From: Dan Cross @ 2022-02-21  1:01 UTC (permalink / raw)
  To: Chester Ramey; +Cc: TUHS main list

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

On Sun, Feb 20, 2022 at 5:42 PM Chet Ramey <chet.ramey@case.edu> wrote:

> On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > Did anyone think about doing this in the past? If yes, what made you
> > decide against doing it?  (Or a streams implementation, for that matter.)
>
> There have been several implementations (I never did one). I suspect that
> the people who were in a position to integrate that functionality into
> distributed kernels were not supportive, or the code didn't get to them
> at the right time.
>

At this point, it feels like the die has been cast. Readline, or something
like it, is "good enough" and those working with something plan9-like don't
need the functionality at all. Arguably, on Unix-style systems it would be
cleaner to do in the kernel, but aside from aesthetics, what's the
incentive to change?

        - Dan C.

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-21  1:01             ` Dan Cross
@ 2022-02-22  4:54               ` Dan Stromberg
  2022-02-22  5:39                 ` Rob Pike
  0 siblings, 1 reply; 30+ messages in thread
From: Dan Stromberg @ 2022-02-22  4:54 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list

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

On Sun, Feb 20, 2022 at 5:05 PM Dan Cross <crossd@gmail.com> wrote:

>
> At this point, it feels like the die has been cast. Readline, or something
> like it, is "good enough" and those working with something plan9-like don't
> need the functionality at all. Arguably, on Unix-style systems it would be
> cleaner to do in the kernel, but aside from aesthetics, what's the
> incentive to change?
>

Actually, isn't it usually better to put functionality in userspace
libraries than inside an OS kernel, where feasible?

Big kernels are buggier and less secure.

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-22  4:54               ` Dan Stromberg
@ 2022-02-22  5:39                 ` Rob Pike
  2022-02-22  5:54                   ` George Michaelson
  0 siblings, 1 reply; 30+ messages in thread
From: Rob Pike @ 2022-02-22  5:39 UTC (permalink / raw)
  To: Dan Stromberg; +Cc: TUHS main list


[-- Attachment #1.1: Type: text/plain, Size: 72 bytes --]

Alea iacta est.

-rob

>
> Big kernels are buggier and less secure.
>
>

[-- Attachment #1.2: Type: text/html, Size: 400 bytes --]

[-- Attachment #2: linux.jpeg --]
[-- Type: image/jpeg, Size: 79964 bytes --]

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

* Re: [TUHS] v7 source code for sh
  2022-02-22  5:39                 ` Rob Pike
@ 2022-02-22  5:54                   ` George Michaelson
  0 siblings, 0 replies; 30+ messages in thread
From: George Michaelson @ 2022-02-22  5:54 UTC (permalink / raw)
  To: TUHS main list

its a logistic supply curve. When it exceeds the available memory, and
we've run out of PDP8 cores to recycle, they declare it's done and
ship V1.0. If you can predict the asymptote, put your Roth on memory
shares!


On Tue, Feb 22, 2022 at 3:42 PM Rob Pike <robpike@gmail.com> wrote:
>
> Alea iacta est.
>
> -rob
>>
>>
>> Big kernels are buggier and less secure.
>>

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

* Re: [TUHS] v7 source code for sh
  2022-02-22  3:07 Brian Walden
  2022-02-22 14:28 ` Chet Ramey
@ 2022-02-22 14:47 ` Clem Cole
  1 sibling, 0 replies; 30+ messages in thread
From: Clem Cole @ 2022-02-22 14:47 UTC (permalink / raw)
  To: Brian Walden; +Cc: tuhs

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

On Mon, Feb 21, 2022 at 10:11 PM Brian Walden <tuhs@cuzuco.com> wrote:

> The one I remember using in the 80s was called "fep" written by
> Kazumasa Utashiro of Software Research Associates. It was probbaly posetd
> posted to comp.sources.unix usenet group.
>

 comp.sources.unix  - volume16
...
fep/ Front end editor program
fep/part01 v16i061:  Front end editor program, Part01/05
fep/part02 v16i062:  Front end editor program, Part02/05
fep/part03 v16i063:  Front end editor program, Part03/05
fep/part04 v16i064:  Front end editor program, Part04/05
fep/part05 v16i065:  Front end editor program, Part05/05


http://sources.vsta.org/comp.sources.unix/volume16/fep/

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-22  3:07 Brian Walden
@ 2022-02-22 14:28 ` Chet Ramey
  2022-02-22 14:47 ` Clem Cole
  1 sibling, 0 replies; 30+ messages in thread
From: Chet Ramey @ 2022-02-22 14:28 UTC (permalink / raw)
  To: Brian Walden, tuhs

On 2/21/22 10:07 PM, Brian Walden wrote:
> The one I remember using in the 80s was called "fep" written by
> Kazumasa Utashiro of Software Research Associates. It was probbaly posetd
> posted to comp.sources.unix usenet group.

I still have a copy of that somewhere.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

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

* Re: [TUHS] v7 source code for sh
@ 2022-02-22  3:07 Brian Walden
  2022-02-22 14:28 ` Chet Ramey
  2022-02-22 14:47 ` Clem Cole
  0 siblings, 2 replies; 30+ messages in thread
From: Brian Walden @ 2022-02-22  3:07 UTC (permalink / raw)
  To: tuhs

The one I remember using in the 80s was called "fep" written by
Kazumasa Utashiro of Software Research Associates. It was probbaly posetd
posted to comp.sources.unix usenet group.

-Brian

Chet Ramey wrote:
> On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > Chet Ramey writes:
> >
> >> It always seemed like it would have been just the thing to implement as a
> >> tty streams module, but research Unix went in a different direction.
> >
> > I'm really surprised nobody has implemented a basic readline as a
> > tty line discipline by now.  I was poking around the OpenBSD NMEA
> > line discipline code a few weeks ago and thinking it shouldn't be
> > that hard to do.
>
> It's not that hard. The complexity is in how sophisticated you want to get
> with redisplay and whether you want to allow user-specified key bindings.
>
> > Did anyone think about doing this in the past? If yes, what made you
> > decide against doing it?  (Or a streams implementation, for that matter.)
>
> There have been several implementations (I never did one). I suspect that
> the people who were in a position to integrate that functionality into
> distributed kernels were not supportive, or the code didn't get to them
> at the right time.
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

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

* Re: [TUHS] v7 source code for sh
  2022-02-21 17:58 Norman Wilson
@ 2022-02-21 18:10 ` Rob Pike
  0 siblings, 0 replies; 30+ messages in thread
From: Rob Pike @ 2022-02-21 18:10 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

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

It was likely me, as I did a lot of work on the program, but I don't claim
that I was the one.

There is a db (the Plan 9 derivation of adb) in plan9port, but it struggles
with modern binaries.

-rob


On Tue, Feb 22, 2022 at 5:00 AM Norman Wilson <norman@oclsc.org> wrote:

> Rob Pike:
>
>   I did the same to adb, which turned out to have a really good debugger
>   hidden under a few serious bugs of its own, which I fixed.
>
> =====
>
> Memories.
>
> Was it you who replaced ptrace with /proc in adb, or did I do that?
>
> I do remember I was the one who took ptrace out of sdb (which a
> few 1127-ers, or perhaps 112-ers on alice and rabbit still used).
> After which I removed ptrace from the kernel, and from the
> copy of the V8 manual in the UNIX room.  Conveniently ptrace
> occupied two facing pages; I glued them together.
>
> I also later did some work to try to isolate the target-dependent
> parts of adb and to make them work in host-independent ways--e.g.
> assembling ints byte-by-byte rather than assuming byte order--to
> make it easier to make a cross adb, e.g. to examine PDP-11 or
> 68K core dumps on a VAX.
>
> I miss adb; maybe it's time to revive it, though these days I'd
> be tempted to rewrite it in Python so I could just load the right
> module at runtime to pick the desired target.
>
> Norman Wilson
> Toronto ON
>

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

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

* Re: [TUHS] v7 source code for sh
@ 2022-02-21 17:58 Norman Wilson
  2022-02-21 18:10 ` Rob Pike
  0 siblings, 1 reply; 30+ messages in thread
From: Norman Wilson @ 2022-02-21 17:58 UTC (permalink / raw)
  To: tuhs

Rob Pike:

  I did the same to adb, which turned out to have a really good debugger
  hidden under a few serious bugs of its own, which I fixed.

=====

Memories.

Was it you who replaced ptrace with /proc in adb, or did I do that?

I do remember I was the one who took ptrace out of sdb (which a
few 1127-ers, or perhaps 112-ers on alice and rabbit still used).
After which I removed ptrace from the kernel, and from the
copy of the V8 manual in the UNIX room.  Conveniently ptrace
occupied two facing pages; I glued them together.

I also later did some work to try to isolate the target-dependent
parts of adb and to make them work in host-independent ways--e.g.
assembling ints byte-by-byte rather than assuming byte order--to
make it easier to make a cross adb, e.g. to examine PDP-11 or
68K core dumps on a VAX.

I miss adb; maybe it's time to revive it, though these days I'd
be tempted to rewrite it in Python so I could just load the right
module at runtime to pick the desired target.

Norman Wilson
Toronto ON

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

* Re: [TUHS] v7 source code for sh
@ 2022-02-20  7:24 Rudi Blom
  0 siblings, 0 replies; 30+ messages in thread
From: Rudi Blom @ 2022-02-20  7:24 UTC (permalink / raw)
  To: tuhs


[-- Attachment #1.1: Type: text/plain, Size: 388 bytes --]

Second half of the 1980-tish when the computer division of Philips
Electronics started on their own Motorola M68010 / UNIX System V.3 (don't
remember for sure I'm afraid) they used a syntax.h with macros similar to
mac.h. Only I understand it's more Pascal like. Appended the 1987 version I
found in my archive.

Cheers,
rubl

-- 
The more I learn the better I understand I know nothing.

[-- Attachment #1.2: Type: text/html, Size: 585 bytes --]

[-- Attachment #2: syntax.h --]
[-- Type: text/plain, Size: 1754 bytes --]

/*	SCCSID(" @(#)syntax.h		87/08/01 )"	*/

#ifndef	SYNTAX_H
#define SYNTAX_H

/* For a full explanation see the file syntax.help */

#define IF		if(
#define THEN		){
#define ELSIF		}else if(
#define ELSE		}else{
#define ENDIF		}
#define NOT		!
#define	AND		&&
#define	OR		||
#define CASE		switch(
#define OF		){
#define ENDCASE		break;}
#define WHEN		break;case
#define CWHEN		case
#define IMPL		:
#define COR		:case
#define BREAK		break
#define WHENOTHERS	break;default
#define CWHENOTHERS	default
#define SELECT		do{{
#define SWHEN		}if(
#define SIMPL		){
#define ENDSELECT	}}while(0)
#define SCOPE		{
#define ENDSCOPE	}
#define BLOCK		{
#define ENDBLOCK	}
#define FOREVER		for(;;
#define FOR		for(
#define SKIP
#define COND		;
#define STEP		;
#define LOOP		){
#define ENDLOOP		}
#define NULLOOP		){}
#define WHILE		while(
#define DO		do{
#define UNTIL		}while(!(
#define ENDDO		))
#define EXITWHEN(e)	if(e)break
#define CONTINUE	continue
#define RETURN		return
#define GOTO		goto
#define STRUCT		struct
#define UNION		union
#define TYPE		typedef
#define IS		
#define SIZEOF		sizeof
#define UNSIGNED	unsigned
#define CHAR		char
#define UCHAR		unsigned char
#define BYTE		char
#define UBYTE		unsigned char
#define SHORT		short
#define USHORT		unsigned short
#define INT		int
#define UINT		unsigned int
#define VOID		void
#define LONG		long
#define ULONG		unsigned long
#define FLOAT		float
#define DOUBLE		double
#define ENUM		enum
#define PRIVATE		static
#define IMPORT		extern
#define EXPORT
#define AUTO		auto
#define FAST		register
#define FALSE		0
#define TRUE		1
#define MODULE(m,id)	static char __mod__[]="m";\
	static char __file__[]=__FILE__;static char __filid__[]="id"
#define PROC		
#define ENDMODULE
#define SHOULD_NOT
#endif	/* SYNTAX_H */

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 16:03 ` Steve Nickolas
  2022-02-19 16:07   ` Clem Cole
  2022-02-19 16:43   ` Steve Nickolas
@ 2022-02-19 17:24   ` Ron Natalie
  2 siblings, 0 replies; 30+ messages in thread
From: Ron Natalie @ 2022-02-19 17:24 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: TUHS main list

This persisted in the shell until S5R2 when someone gratefully undid all those macros.  adb was similarly afflicted. 

> On Feb 19, 2022, at 11:04, Steve Nickolas <usotsuki@buric.co> wrote:
> 
> On Sat, 19 Feb 2022, Will Senn wrote:
>> I have been poring through the v7 source code lately, and came across an oddity I would like to know more about. Specifically, in sh. The code for sh is c, but it makes *extensive* use of of macros, for example:
> 
> <snip>
> 
>> I can read the resultant code through the lens of my experience coding c, but I'm curious why the macros and how this came about? In v6, the sh source is straight up c. Is there a story behind it worth knowing?
> 
> Apparently Bourne was heavily into ALGOL, and used those macros to make C into something more familiar.
> 
> At least, that's what I concluded by reading her Wikipedia page as well as the code.
> 
> -uso.


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

* Re: [TUHS] v7 source code for sh
  2022-02-19 16:06 ` Bakul Shah
@ 2022-02-19 16:57   ` Will Senn
  0 siblings, 0 replies; 30+ messages in thread
From: Will Senn @ 2022-02-19 16:57 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

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

Thanks Bakul, that's interesting.

Impetus for the obfuscated c contest?! The same contest where a guy 
wrote a pdp11 emulator capable of running v0, v6, and 2.9bsd in 50 lines 
of c (Mills, 2018)? I still get a kick out of that code. Particularly 
because you can run Mullender's 1984 entry on the 2.9 bsd instance it 
hosts (it also works in v7, but it's too fast, even with stty 300).

Thankfully, macros, while adding an additional layer of complexity, 
aren't as impenetrable as the ioccc stuff:

    mills's prog.c snippet:
    struct timeval F,G; struct termios H,U={ T} ; enum{
    N=64,a=N<<7,b=a-1,c=a*32,d
    =c-1,    e=c/    2,f=    a*2,    g=a/2,h =g/2,j =h/ 2,Q=V*j*5} ;
    char*s=P,K,M;
    int*      p,      l[      a]      ,m,n,J,o=A,
    O=j,E,R,i,k,t,r,q,u,v,w,x,y,z
    ,B,C,    *D,Z    ;int    main    (){ for(D=mmap...

    mullender's mullender.c in it's entirety (requires v7 or better and
    pdp11):
    short main[] = {
         277, 04735, -4129, 25, 0, 477, 1019, 0xbef, 0, 12800,
         -113, 21119, 0x52d7, -1006, -7151, 0, 0x4bc, 020004,
         14880, 10541, 2056, 04010, 4548, 3044, -6716, 0x9,
         4407, 6, 5568, 1, -30460, 0, 0x9, 5570, 512, -30419,
         0x7e82, 0760, 6, 0, 4, 02400, 15, 0, 4, 1280, 4, 0,
         4, 0, 0, 0, 0x8, 0, 4, 0, ',', 0, 12, 0, 4, 0, '#',
         0, 020, 0, 4, 0, 30, 0, 026, 0, 0x6176, 120, 25712,
         'p', 072163, 'r', 29303, 29801, 'e'
    };

Later,

Will



On 2/19/22 10:06 AM, Bakul Shah wrote:
> https://research.swtch.com/shmacro
>
>> On Feb 19, 2022, at 7:44 AM, Will Senn <will.senn@gmail.com> wrote:
>>
>>  I have been poring through the v7 source code lately, and came 
>> across an oddity I would like to know more about. Specifically, in 
>> sh. The code for sh is c, but it makes *extensive* use of of macros, 
>> for example:
>>
>>     /usr/src/cmd/sh/word.c
>>     ...
>>     WHILE (c=nextc(0), space(c)) DONE
>>     ...
>>
>> The macros for sh are defined in mac.h:
>>
>>     /usr/src/cmd/sh/mac.h
>>     ...
>>     #define BEGIN   {
>>     #define END     }
>>     #define SWITCH  switch(
>>     #define IN      ){
>>     #define ENDSW   }
>>     #define FOR     for(
>>     #define WHILE   while(
>>     #define DO      ){
>>     #define OD      ;}
>>     #define REP     do{
>>     #define PER     }while(
>>     #define DONE    );
>>     ...
>>
>> I can read the resultant code through the lens of my experience 
>> coding c, but I'm curious why the macros and how this came about? In 
>> v6, the sh source is straight up c. Is there a story behind it worth 
>> knowing?
>>
>> Thanks,
>>
>> Will

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 16:03 ` Steve Nickolas
  2022-02-19 16:07   ` Clem Cole
@ 2022-02-19 16:43   ` Steve Nickolas
  2022-02-19 17:24   ` Ron Natalie
  2 siblings, 0 replies; 30+ messages in thread
From: Steve Nickolas @ 2022-02-19 16:43 UTC (permalink / raw)
  To: TUHS main list

On Sat, 19 Feb 2022, Steve Nickolas wrote:

> At least, that's what I concluded by reading her Wikipedia page as well as 
> the code.

Oops, braino.  Obviously I meant "his"

-uso.

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 16:03 ` Steve Nickolas
@ 2022-02-19 16:07   ` Clem Cole
  2022-02-19 16:43   ` Steve Nickolas
  2022-02-19 17:24   ` Ron Natalie
  2 siblings, 0 replies; 30+ messages in thread
From: Clem Cole @ 2022-02-19 16:07 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: TUHS main list

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

On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas <usotsuki@buric.co> wrote:

> Apparently Bourne was heavily into ALGOL,
>
That's sort of an understatement.  I believe that when he was at Cambridge,
he was one of the people that helped to take the Algol-X proposal and
turned it into the Algol-68 definition. I also believe he worked on their
famous implementation of same.

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 15:43 Will Senn
  2022-02-19 16:03 ` Steve Nickolas
  2022-02-19 16:04 ` Clem Cole
@ 2022-02-19 16:06 ` Bakul Shah
  2022-02-19 16:57   ` Will Senn
  2 siblings, 1 reply; 30+ messages in thread
From: Bakul Shah @ 2022-02-19 16:06 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

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

https://research.swtch.com/shmacro

> On Feb 19, 2022, at 7:44 AM, Will Senn <will.senn@gmail.com> wrote:
> 
>  I have been poring through the v7 source code lately, and came across an oddity I would like to know more about. Specifically, in sh. The code for sh is c, but it makes extensive use of of macros, for example:
> /usr/src/cmd/sh/word.c
> ...
> WHILE (c=nextc(0), space(c)) DONE
> ...
> 
> The macros for sh are defined in mac.h:
> /usr/src/cmd/sh/mac.h
> ...
> #define BEGIN   {
> #define END     }
> #define SWITCH  switch(
> #define IN      ){
> #define ENDSW   }
> #define FOR     for(
> #define WHILE   while(
> #define DO      ){
> #define OD      ;}
> #define REP     do{
> #define PER     }while(
> #define DONE    );
> ...
> I can read the resultant code through the lens of my experience coding c, but I'm curious why the macros and how this came about? In v6, the sh source is straight up c. Is there a story behind it worth knowing?
> 
> Thanks,
> 
> Will

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 15:43 Will Senn
  2022-02-19 16:03 ` Steve Nickolas
@ 2022-02-19 16:04 ` Clem Cole
  2022-02-19 16:06 ` Bakul Shah
  2 siblings, 0 replies; 30+ messages in thread
From: Clem Cole @ 2022-02-19 16:04 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

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

Sure - this is lovingly referred to as 'Bourne-gol.'  Steve Bourne was part
of the Algol-68 development team at Cambridge before he came to BTL.
Besides his being the 'editor' / 'release manager' of V7 (as Dennis is said
to exclaimed 'never again' after V6), please also look at the sources to
adb, srb's other major contribution (it is also written using his same
macros).  It's also why the syntax of his shell is basically Algol syntax.

Clem

On Sat, Feb 19, 2022 at 10:44 AM Will Senn <will.senn@gmail.com> wrote:

> I have been poring through the v7 source code lately, and came across an
> oddity I would like to know more about. Specifically, in sh. The code for
> sh is c, but it makes *extensive* use of of macros, for example:
>
> /usr/src/cmd/sh/word.c
> ...
> WHILE (c=nextc(0), space(c)) DONE
> ...
>
> The macros for sh are defined in mac.h:
>
> /usr/src/cmd/sh/mac.h
> ...
> #define BEGIN   {
> #define END     }
> #define SWITCH  switch(
> #define IN      ){
> #define ENDSW   }
> #define FOR     for(
> #define WHILE   while(
> #define DO      ){
> #define OD      ;}
> #define REP     do{
> #define PER     }while(
> #define DONE    );
> ...
>
> I can read the resultant code through the lens of my experience coding c,
> but I'm curious why the macros and how this came about? In v6, the sh
> source is straight up c. Is there a story behind it worth knowing?
>
> Thanks,
>
> Will
>

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

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

* Re: [TUHS] v7 source code for sh
  2022-02-19 15:43 Will Senn
@ 2022-02-19 16:03 ` Steve Nickolas
  2022-02-19 16:07   ` Clem Cole
                     ` (2 more replies)
  2022-02-19 16:04 ` Clem Cole
  2022-02-19 16:06 ` Bakul Shah
  2 siblings, 3 replies; 30+ messages in thread
From: Steve Nickolas @ 2022-02-19 16:03 UTC (permalink / raw)
  To: TUHS main list

On Sat, 19 Feb 2022, Will Senn wrote:

> I have been poring through the v7 source code lately, and came across an 
> oddity I would like to know more about. Specifically, in sh. The code for sh 
> is c, but it makes *extensive* use of of macros, for example:

<snip>

> I can read the resultant code through the lens of my experience coding c, but 
> I'm curious why the macros and how this came about? In v6, the sh source is 
> straight up c. Is there a story behind it worth knowing?

Apparently Bourne was heavily into ALGOL, and used those macros to make C 
into something more familiar.

At least, that's what I concluded by reading her Wikipedia page as well as 
the code.

-uso.

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

* [TUHS] v7 source code for sh
@ 2022-02-19 15:43 Will Senn
  2022-02-19 16:03 ` Steve Nickolas
                   ` (2 more replies)
  0 siblings, 3 replies; 30+ messages in thread
From: Will Senn @ 2022-02-19 15:43 UTC (permalink / raw)
  To: TUHS main list

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

I have been poring through the v7 source code lately, and came across an 
oddity I would like to know more about. Specifically, in sh. The code 
for sh is c, but it makes *extensive* use of of macros, for example:

    /usr/src/cmd/sh/word.c
    ...
    WHILE (c=nextc(0), space(c)) DONE
    ...

The macros for sh are defined in mac.h:

    /usr/src/cmd/sh/mac.h
    ...
    #define BEGIN   {
    #define END     }
    #define SWITCH  switch(
    #define IN      ){
    #define ENDSW   }
    #define FOR     for(
    #define WHILE   while(
    #define DO      ){
    #define OD      ;}
    #define REP     do{
    #define PER     }while(
    #define DONE    );
    ...

I can read the resultant code through the lens of my experience coding 
c, but I'm curious why the macros and how this came about? In v6, the sh 
source is straight up c. Is there a story behind it worth knowing?

Thanks,

Will

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

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

end of thread, other threads:[~2022-02-22 14:50 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-19 17:44 [TUHS] v7 source code for sh Bakul Shah
2022-02-19 18:44 ` Rob Pike
2022-02-19 19:29   ` Clem Cole
2022-02-19 22:39   ` John Cowan
2022-02-19 23:11     ` Sven Mascheck
2022-02-19 23:34       ` Rob Pike
2022-02-19 23:36       ` silas poulson
2022-02-20 20:54       ` Chet Ramey
2022-02-20 21:02         ` Larry McVoy
2022-02-20 21:19           ` Chet Ramey
2022-02-20 21:19         ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-02-20 22:39           ` Chet Ramey
2022-02-21  1:01             ` Dan Cross
2022-02-22  4:54               ` Dan Stromberg
2022-02-22  5:39                 ` Rob Pike
2022-02-22  5:54                   ` George Michaelson
  -- strict thread matches above, loose matches on Subject: below --
2022-02-22  3:07 Brian Walden
2022-02-22 14:28 ` Chet Ramey
2022-02-22 14:47 ` Clem Cole
2022-02-21 17:58 Norman Wilson
2022-02-21 18:10 ` Rob Pike
2022-02-20  7:24 Rudi Blom
2022-02-19 15:43 Will Senn
2022-02-19 16:03 ` Steve Nickolas
2022-02-19 16:07   ` Clem Cole
2022-02-19 16:43   ` Steve Nickolas
2022-02-19 17:24   ` Ron Natalie
2022-02-19 16:04 ` Clem Cole
2022-02-19 16:06 ` Bakul Shah
2022-02-19 16:57   ` Will Senn

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