The Unix Heritage Society mailing list
 help / color / Atom feed
* [TUHS] Warner's Early Unix Presentation
@ 2020-02-07 22:25 Warren Toomey
  2020-02-07 23:57 ` Rob Pike
  0 siblings, 1 reply; 61+ messages in thread
From: Warren Toomey @ 2020-02-07 22:25 UTC (permalink / raw)
  To: tuhs

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

https://fosdem.org/2020/schedule/event/early_unix/

The video of Warner Losh's FOSDEM presentation "The Hidden Early History of Unix" is now available.

Cheers, Warren
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-07 22:25 [TUHS] Warner's Early Unix Presentation Warren Toomey
@ 2020-02-07 23:57 ` Rob Pike
  2020-02-08  0:43   ` Warren Toomey
  2020-02-08 15:15   ` Warner Losh
  0 siblings, 2 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-07 23:57 UTC (permalink / raw)
  To: Warren Toomey; +Cc: The Eunuchs Hysterical Society

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

Very nice talk with lots of good background. It made me think of the boxes
of DECTapes we had under the Unix room floor, and what we might have lost.
(Volunteers did manage to recover a couple of them, but time was short).

PWB inaccuracy: The talk said that tools like grep and sed came from PWB,
but that's not true. They were original, as I'm sure Warner knows; he just
misspoke. Slightly more important: PWB also did not introduce the idea of
the shell (neither did Unix, for that matter), although there was a
distinct shell for that system that included the legendary pump operator,
later superseded by here documents. The flow from PWB back to the main
research line was a trickle at best. We had bad NIH in 1127.

-rob

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-07 23:57 ` Rob Pike
@ 2020-02-08  0:43   ` Warren Toomey
  2020-02-08  3:37     ` Warner Losh
  2020-02-08 15:15   ` Warner Losh
  1 sibling, 1 reply; 61+ messages in thread
From: Warren Toomey @ 2020-02-08  0:43 UTC (permalink / raw)
  To: tuhs

On Sat, Feb 08, 2020 at 10:57:41AM +1100, Rob Pike wrote:
>    Slightly more important: PWB also did not introduce
>    the idea of the shell (neither did Unix, for that matter) ...

Yes, we should ask Warner what he meant here. I thought perhaps he meant
a shell which allowed scripts.

Also, another nitpick not just for Warner but for a few talks I've seen
over the past 12 months. TUHS is the Unix _Heritage_ Society not the
Unix Historical Society :-)

I don't mind either way, happy for us to get some attention!

Cheers all, Warren

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08  0:43   ` Warren Toomey
@ 2020-02-08  3:37     ` Warner Losh
  0 siblings, 0 replies; 61+ messages in thread
From: Warner Losh @ 2020-02-08  3:37 UTC (permalink / raw)
  To: Warren Toomey; +Cc: The Eunuchs Hysterical Society

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

On Fri, Feb 7, 2020, 5:44 PM Warren Toomey <wkt@tuhs.org> wrote:

> On Sat, Feb 08, 2020 at 10:57:41AM +1100, Rob Pike wrote:
> >    Slightly more important: PWB also did not introduce
> >    the idea of the shell (neither did Unix, for that matter) ...
>
> Yes, we should ask Warner what he meant here. I thought perhaps he meant
> a shell which allowed script
>

Yes. I meant the first shell that allowed real scripting.

Also, another nitpick not just for Warner but for a few talks I've seen
> over the past 12 months. TUHS is the Unix _Heritage_ Society not the
> Unix Historical Society :-)
>

Doh!

I don't mind either way, happy for us to get some attention!
>
> Cheers all, Warren
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-07 23:57 ` Rob Pike
  2020-02-08  0:43   ` Warren Toomey
@ 2020-02-08 15:15   ` Warner Losh
  2020-02-08 21:50     ` Rob Pike
  1 sibling, 1 reply; 61+ messages in thread
From: Warner Losh @ 2020-02-08 15:15 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

On Fri, Feb 7, 2020 at 4:58 PM Rob Pike <robpike@gmail.com> wrote:

> Very nice talk with lots of good background. It made me think of the boxes
> of DECTapes we had under the Unix room floor, and what we might have lost.
> (Volunteers did manage to recover a couple of them, but time was short).
>

That makes me sad... :( It seems weird: in the Unix room were also all the
binders of PDP-7 code that we've retyped in. I wonder if that was
considered the archive for early unix, and that may be why we don't have
enough early unix artifacts before the 5th edition? I know it was a bit of
a rolling release, but I would have thought that ken or dmr would have made
archival copies of the system around 'manual edition day' given all the
other artifacts they saved.


> PWB inaccuracy: The talk said that tools like grep and sed came from PWB,
> but that's not true. They were original, as I'm sure Warner knows; he just
> misspoke.
>

Yes. I got confused. In the talk the organizers flashed the time signs too
early so I got nervous and rushed through some bits (it didn't help that
this was the largest room I've spoken to and it was in the 'lunch coma'
spot so some people fell asleep). I also never have a script for the talks,
just a good understanding of the material and a rough list of points I'd
like to make...  And at the last minute I thought it would be better to
characterize all the v4-based systems as the early forks and de-emphasize
that SCCS Unix -> CB Unix was the first fork, so I thought I made that
point a little more awkwardly than I would have liked.


> Slightly more important: PWB also did not introduce the idea of the shell
> (neither did Unix, for that matter), although there was a distinct shell
> for that system that included the legendary pump operator, later superseded
> by here documents.
>

Yes. I'd only mean that pwb enabled people to start writing real,
non-trivial shell scripts. There's other scripts in the tree prior to
Bourne Shell...  There's several 'runit' scripts that look to build things
pre-make. There's also sources to 'goto.c' which implemented 'goto label'
by rewinding stdin until it finds the label then exiting (I presume the
older shell would then start reading again from stdin). Or maybe I've
totally missed the point of s1/goto.c... there's no comments in it. It is a
bit of a stretch, though, you're right.


> The flow from PWB back to the main research line was a trickle at best. We
> had bad NIH in 1127.
>

That matches other sources I've seen: bug fixes flowed into research
relatively easily. Performance fixes sometimes (though often not). Some
drivers did. And only the occasional program. It's my belief that this slow
level of flow is why AT&T shifted from the Research line to the Unix/TS
line and merged Unix/TS and PWB into Unix/TS 3.0 (System III was 3.0.1) and
roped other internal lines into Unix/TS 4.0 and/or System V. I also now
wonder if we got the Bourne Shell because of NIH or because there was some
clear technical defect in pwbsh that Steve Bourne was correcting... There
were no env vars before V7, and I haven't looked at the pwb sh to see how
that issue was handled. I'll have to also include the 'pump' operator in
future talks.

Warner

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 15:15   ` Warner Losh
@ 2020-02-08 21:50     ` Rob Pike
  2020-02-08 22:29       ` Chet Ramey
                         ` (3 more replies)
  0 siblings, 4 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-08 21:50 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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

>
>
> Yes. I'd only mean that pwb enabled people to start writing real,
> non-trivial shell scripts. There's other scripts in the tree prior to
> Bourne Shell...  There's several 'runit' scripts that look to build things
> pre-make. There's also sources to 'goto.c' which implemented 'goto label'
> by rewinding stdin until it finds the label then exiting (I presume the
> older shell would then start reading again from stdin). Or maybe I've
> totally missed the point of s1/goto.c... there's no comments in it. It is a
> bit of a stretch, though, you're right.
>

That's how goto worked, yes.

The flow from PWB back to the main research line was a trickle at best. We
>> had bad NIH in 1127.
>>
>
> That matches other sources I've seen: bug fixes flowed into research
> relatively easily. Performance fixes sometimes (though often not). Some
> drivers did. And only the occasional program. It's my belief that this slow
> level of flow is why AT&T shifted from the Research line to the Unix/TS
> line and merged Unix/TS and PWB into Unix/TS 3.0 (System III was 3.0.1) and
> roped other internal lines into Unix/TS 4.0 and/or System V.
>

I think the SysV/Research split is just another variant of NIH and separate
organizations. The development folks did what they did because it helped
them (or perhaps just to have fun?). Features in CB Unix bothered us (like
the way init worked) and although we were pressured to take them, we
resisted. USG was more accommodating. They (USG, Unix Support Group) were
just that: a support group, and they were under immense pressure from their
users in the Bell System to add features. There was outright mockery from
us at how complex stty became, and then the ultimate insult arrived, ioctl.
So System V was theirs, managed by them, owned by them. Occasionally we'd
go to meetings there to try to convince them to do something differently. I
remember a meeting where I tried to talk them out of some truly awful
shared memory or IPC thing, but the details are hazy. I'm sure they ignored
me anyway; in general they didn't listen to us unless their users were
asking for something we had.


> I also now wonder if we got the Bourne Shell because of NIH or because
> there was some clear technical defect in pwbsh that Steve Bourne was
> correcting... There were no env vars before V7, and I haven't looked at the
> pwb sh to see how that issue was handled. I'll have to also include the
> 'pump' operator in future talks.
>

Mashey's shell was better than the v6 shell, no question, but it was still
pretty clunky and undisciplined. If I remember right, it was a hacked up v6
shell, but I'm not sure.

Steve Bourne, who understands formal languages and was (clearly!) a fan of
Algol 68, decided a more structured approach was necessary. People malign
the look of the code, but his research shell was lovely. For v8 I ripped
the IF ELIF macros out; they were just sugar I could scrape off. I put in
shell functions, which Steve had wanted to do anyway, made them exportable
(fought for that hard at a POSIX meeting, with Ken) and did some cleanups
to the printing etc. so it worked well when you cut and paste from the
terminal. All that was easy to do because the code was so clean. I learned
a lot working on that program. The parser is a jewel. I still think it's a
great piece of code, and I miss the v8 shell every day. The GNU "Bourne
again" shell is missing all that stuff I did.

Unfortunately, Steve's memory allocation trick, mallocking on faults, isn't
portable, and I suspect the code will never run on a modern OS. Tom Duff's
rc was done as a reaction to the shell being, despite its other glories,
still a macro language. But that's another story.

-rob

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 21:50     ` Rob Pike
@ 2020-02-08 22:29       ` Chet Ramey
  2020-02-08 22:54         ` Rob Pike
  2020-02-08 22:31       ` Richard Salz
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 61+ messages in thread
From: Chet Ramey @ 2020-02-08 22:29 UTC (permalink / raw)
  To: Rob Pike, Warner Losh; +Cc: The Eunuchs Hysterical Society

On 2/8/20 4:50 PM, Rob Pike wrote:
> The GNU "Bourne
> again" shell is missing all that stuff I did.

Like what, for instance?


-- 
``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] 61+ messages in thread

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 21:50     ` Rob Pike
  2020-02-08 22:29       ` Chet Ramey
@ 2020-02-08 22:31       ` Richard Salz
  2020-02-10 13:18       ` Tony Finch
  2020-02-10 15:05       ` Dan Cross
  3 siblings, 0 replies; 61+ messages in thread
From: Richard Salz @ 2020-02-08 22:31 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

>
>   Tom Duff's rc was done as a reaction to the shell being, despite its
> other glories, still a macro language. But that's another story.
>

As a user of Byron's clone (it's been my login for ever), I would like to
hear that story.

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 22:29       ` Chet Ramey
@ 2020-02-08 22:54         ` Rob Pike
  2020-02-08 23:02           ` Chet Ramey
  0 siblings, 1 reply; 61+ messages in thread
From: Rob Pike @ 2020-02-08 22:54 UTC (permalink / raw)
  To: chet.ramey; +Cc: The Eunuchs Hysterical Society

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

Like exportable functions and output that's valid input, so it works well
with an editable typescript.

-rob


On Sun, Feb 9, 2020 at 9:29 AM Chet Ramey <chet.ramey@case.edu> wrote:

> On 2/8/20 4:50 PM, Rob Pike wrote:
> > The GNU "Bourne
> > again" shell is missing all that stuff I did.
>
> Like what, for instance?
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 22:54         ` Rob Pike
@ 2020-02-08 23:02           ` Chet Ramey
  2020-02-08 23:11             ` Rob Pike
  0 siblings, 1 reply; 61+ messages in thread
From: Chet Ramey @ 2020-02-08 23:02 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

On 2/8/20 5:54 PM, Rob Pike wrote:
> Like exportable functions and output that's valid input, so it works well
> with an editable typescript.

Bash has both of those things.

-- 
``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] 61+ messages in thread

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:02           ` Chet Ramey
@ 2020-02-08 23:11             ` Rob Pike
  2020-02-08 23:13               ` Rob Pike
                                 ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-08 23:11 UTC (permalink / raw)
  To: chet.ramey; +Cc: The Eunuchs Hysterical Society

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

Not for me it doesn't.

% bash

bash-3.2$ function f() {

    echo hi

    }

bash-3.2$ export f

bash-3.2$ bash

bash-3.2$ f

bash-3.2$


I added the 'builtin' command, which did leave the labs. But I added it as
a way for the "whatis" command to show a builtin, as well as allowing a way
to guarantee you get the builtin on execution.


How do I get bash to print the function as (shell) source code, so I could
edit it and play with it again? It was the synergy of all this stuff
connected seamlessly that made it so compelling.


-rob



On Sun, Feb 9, 2020 at 10:02 AM Chet Ramey <chet.ramey@case.edu> wrote:

> On 2/8/20 5:54 PM, Rob Pike wrote:
> > Like exportable functions and output that's valid input, so it works well
> > with an editable typescript.
>
> Bash has both of those things.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:11             ` Rob Pike
@ 2020-02-08 23:13               ` Rob Pike
  2020-02-08 23:21               ` Kurt H Maier
  2020-02-08 23:26               ` Chet Ramey
  2 siblings, 0 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-08 23:13 UTC (permalink / raw)
  To: chet.ramey; +Cc: The Eunuchs Hysterical Society

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

Here is rc, which absorbed most of that behavior from the v8 shell:

% rc

% fn f { echo hi }

% whatis f

fn f {echo hi}

% whatis path

path=(. /Users/r/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin
/usr/local/go/bin /Applications/Keybase.app/Contents/SharedSupport/bin
/usr/local/plan9/bin)

% rc

% # subshell

% f

hi

%




On Sun, Feb 9, 2020 at 10:11 AM Rob Pike <robpike@gmail.com> wrote:

> Not for me it doesn't.
>
> % bash
>
> bash-3.2$ function f() {
>
>     echo hi
>
>     }
>
> bash-3.2$ export f
>
> bash-3.2$ bash
>
> bash-3.2$ f
>
> bash-3.2$
>
>
> I added the 'builtin' command, which did leave the labs. But I added it as
> a way for the "whatis" command to show a builtin, as well as allowing a way
> to guarantee you get the builtin on execution.
>
>
> How do I get bash to print the function as (shell) source code, so I could
> edit it and play with it again? It was the synergy of all this stuff
> connected seamlessly that made it so compelling.
>
>
> -rob
>
>
>
> On Sun, Feb 9, 2020 at 10:02 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
>> On 2/8/20 5:54 PM, Rob Pike wrote:
>> > Like exportable functions and output that's valid input, so it works
>> well
>> > with an editable typescript.
>>
>> Bash has both of those things.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>                  ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>>
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:11             ` Rob Pike
  2020-02-08 23:13               ` Rob Pike
@ 2020-02-08 23:21               ` Kurt H Maier
  2020-02-08 23:26                 ` Rob Pike
  2020-02-08 23:26               ` Chet Ramey
  2 siblings, 1 reply; 61+ messages in thread
From: Kurt H Maier @ 2020-02-08 23:21 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

On Sun, Feb 09, 2020 at 10:11:06AM +1100, Rob Pike wrote:
>
> bash-3.2$ export f
>
       
You need export -f f here.
       
>
> How do I get bash to print the function as (shell) source code, so I
> could edit it and play with it again?
         
$ type f
f is a function
f ()
{
    echo hi
}


I don't like bash, but it has every feature ever thought of.  Maybe I
could better phrase that:  I don't like bash, because it has every
feature ever thought of.
        
khm

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:21               ` Kurt H Maier
@ 2020-02-08 23:26                 ` Rob Pike
  2020-02-08 23:28                   ` Chet Ramey
  0 siblings, 1 reply; 61+ messages in thread
From: Rob Pike @ 2020-02-08 23:26 UTC (permalink / raw)
  To: Kurt H Maier; +Cc: The Eunuchs Hysterical Society

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

That 'f is a function' header weakens the idea substantially.

Anyway, it's good to see these ideas picked up, if late and imperfectly. My
work on the v8 shell was a long time ago.

-rob


On Sun, Feb 9, 2020 at 10:21 AM Kurt H Maier <khm@sciops.net> wrote:

> On Sun, Feb 09, 2020 at 10:11:06AM +1100, Rob Pike wrote:
> >
> > bash-3.2$ export f
> >
>
> You need export -f f here.
>
> >
> > How do I get bash to print the function as (shell) source code, so I
> > could edit it and play with it again?
>
> $ type f
> f is a function
> f ()
> {
>     echo hi
> }
>
>
> I don't like bash, but it has every feature ever thought of.  Maybe I
> could better phrase that:  I don't like bash, because it has every
> feature ever thought of.
>
> khm
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:11             ` Rob Pike
  2020-02-08 23:13               ` Rob Pike
  2020-02-08 23:21               ` Kurt H Maier
@ 2020-02-08 23:26               ` Chet Ramey
  2020-02-08 23:29                 ` Rob Pike
  2 siblings, 1 reply; 61+ messages in thread
From: Chet Ramey @ 2020-02-08 23:26 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

On 2/8/20 6:11 PM, Rob Pike wrote:
> Not for me it doesn't.
> 
> % bash
> 
> bash-3.2$ function f() {
> 
>     echo hi
> 
>     }
> 
> bash-3.2$ export f 
> bash-3.2$ bash 
> bash-3.2$ f 
> bash-3.2$ 

jenna(1)$ echo $BASH_VERSION
5.0.11(6)-release
jenna(1)$ f() { echo f; }
jenna(1)$ export -f f
jenna(1)$ bash
jenna(2)$ f
f
jenna(2)$

It works the same in Mac OS X's bash-3.2.

> I added the 'builtin' command, which did leave the labs. But I added it as
> a way for the "whatis" command to show a builtin, as well as allowing a way
> to guarantee you get the builtin on execution.

Bash uses `type' to tell whether something is a builtin. How does `builtin'
say whether or not a command is builtin? The output with no arguments?

> How do I get bash to print the function as (shell) source code, so I could
> edit it and play with it again? It was the synergy of all this stuff
> connected seamlessly that made it so compelling.
> 

jenna(2)$ declare -pf f
f ()
{
    echo f
}
declare -fx f

If it weren't exported, you wouldn't get the `declare' command appended
there.

-- 
``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] 61+ messages in thread

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:26                 ` Rob Pike
@ 2020-02-08 23:28                   ` Chet Ramey
  0 siblings, 0 replies; 61+ messages in thread
From: Chet Ramey @ 2020-02-08 23:28 UTC (permalink / raw)
  To: Rob Pike, Kurt H Maier; +Cc: The Eunuchs Hysterical Society

On 2/8/20 6:26 PM, Rob Pike wrote:
> That 'f is a function' header weakens the idea substantially.

Use `declare -fp f' to get what you want.

-- 
``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] 61+ messages in thread

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:26               ` Chet Ramey
@ 2020-02-08 23:29                 ` Rob Pike
  2020-02-08 23:35                   ` Warner Losh
                                     ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-08 23:29 UTC (permalink / raw)
  To: chet.ramey; +Cc: The Eunuchs Hysterical Society

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

% rc

% whatis cd

builtin cd

%


It's much simpler this way. The output is the executable input, free of
decoration and ready to use.


In today's Unix (I use the term loosely) world, the phrase "free of
decoration" is apostasy.


-rob



On Sun, Feb 9, 2020 at 10:26 AM Chet Ramey <chet.ramey@case.edu> wrote:

> On 2/8/20 6:11 PM, Rob Pike wrote:
> > Not for me it doesn't.
> >
> > % bash
> >
> > bash-3.2$ function f() {
> >
> >     echo hi
> >
> >     }
> >
> > bash-3.2$ export f
> > bash-3.2$ bash
> > bash-3.2$ f
> > bash-3.2$
>
> jenna(1)$ echo $BASH_VERSION
> 5.0.11(6)-release
> jenna(1)$ f() { echo f; }
> jenna(1)$ export -f f
> jenna(1)$ bash
> jenna(2)$ f
> f
> jenna(2)$
>
> It works the same in Mac OS X's bash-3.2.
>
> > I added the 'builtin' command, which did leave the labs. But I added it
> as
> > a way for the "whatis" command to show a builtin, as well as allowing a
> way
> > to guarantee you get the builtin on execution.
>
> Bash uses `type' to tell whether something is a builtin. How does `builtin'
> say whether or not a command is builtin? The output with no arguments?
>
> > How do I get bash to print the function as (shell) source code, so I
> could
> > edit it and play with it again? It was the synergy of all this stuff
> > connected seamlessly that made it so compelling.
> >
>
> jenna(2)$ declare -pf f
> f ()
> {
>     echo f
> }
> declare -fx f
>
> If it weren't exported, you wouldn't get the `declare' command appended
> there.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:29                 ` Rob Pike
@ 2020-02-08 23:35                   ` Warner Losh
  2020-02-08 23:36                   ` Chet Ramey
  2020-02-09  0:19                   ` Larry McVoy
  2 siblings, 0 replies; 61+ messages in thread
From: Warner Losh @ 2020-02-08 23:35 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

On Sat, Feb 8, 2020, 4:29 PM Rob Pike <robpike@gmail.com> wrote:

> % rc
>
> % whatis cd
>
> builtin cd
>
> %
>
>
> It's much simpler this way. The output is the executable input, free of
> decoration and ready to use.
>
>
> In today's Unix (I use the term loosely) world, the phrase "free of
> decoration" is apostasy.
>

A number of utilities have a special flag to use in shell scripts to remove
the decorations. I both like and loath this design pattern.

Warner

-rob
>
>
>
> On Sun, Feb 9, 2020 at 10:26 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
>> On 2/8/20 6:11 PM, Rob Pike wrote:
>> > Not for me it doesn't.
>> >
>> > % bash
>> >
>> > bash-3.2$ function f() {
>> >
>> >     echo hi
>> >
>> >     }
>> >
>> > bash-3.2$ export f
>> > bash-3.2$ bash
>> > bash-3.2$ f
>> > bash-3.2$
>>
>> jenna(1)$ echo $BASH_VERSION
>> 5.0.11(6)-release
>> jenna(1)$ f() { echo f; }
>> jenna(1)$ export -f f
>> jenna(1)$ bash
>> jenna(2)$ f
>> f
>> jenna(2)$
>>
>> It works the same in Mac OS X's bash-3.2.
>>
>> > I added the 'builtin' command, which did leave the labs. But I added it
>> as
>> > a way for the "whatis" command to show a builtin, as well as allowing a
>> way
>> > to guarantee you get the builtin on execution.
>>
>> Bash uses `type' to tell whether something is a builtin. How does
>> `builtin'
>> say whether or not a command is builtin? The output with no arguments?
>>
>> > How do I get bash to print the function as (shell) source code, so I
>> could
>> > edit it and play with it again? It was the synergy of all this stuff
>> > connected seamlessly that made it so compelling.
>> >
>>
>> jenna(2)$ declare -pf f
>> f ()
>> {
>>     echo f
>> }
>> declare -fx f
>>
>> If it weren't exported, you wouldn't get the `declare' command appended
>> there.
>>
>> --
>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>                  ``Ars longa, vita brevis'' - Hippocrates
>> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>>
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:29                 ` Rob Pike
  2020-02-08 23:35                   ` Warner Losh
@ 2020-02-08 23:36                   ` Chet Ramey
  2020-02-08 23:54                     ` Rob Pike
  2020-02-09  0:19                   ` Larry McVoy
  2 siblings, 1 reply; 61+ messages in thread
From: Chet Ramey @ 2020-02-08 23:36 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

On 2/8/20 6:29 PM, Rob Pike wrote:
> % rc
> 
> % whatis cd
> 
> builtin cd
> 
> % 
> 
> 
> It's much simpler this way. The output is the executable input, free of
> decoration and ready to use.

OK. `whatis' is a non-starter as a builtin, but bash ships with an example
`whatis' shell function that does this.

-- 
``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] 61+ messages in thread

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:36                   ` Chet Ramey
@ 2020-02-08 23:54                     ` Rob Pike
  2020-02-09  0:11                       ` Chet Ramey
  0 siblings, 1 reply; 61+ messages in thread
From: Rob Pike @ 2020-02-08 23:54 UTC (permalink / raw)
  To: chet.ramey; +Cc: The Eunuchs Hysterical Society

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

Well, "whatis" was a fine starter in 1983.

I'm not saying anything should change. This is a history list.

-rob


On Sun, Feb 9, 2020 at 10:36 AM Chet Ramey <chet.ramey@case.edu> wrote:

> On 2/8/20 6:29 PM, Rob Pike wrote:
> > % rc
> >
> > % whatis cd
> >
> > builtin cd
> >
> > %
> >
> >
> > It's much simpler this way. The output is the executable input, free of
> > decoration and ready to use.
>
> OK. `whatis' is a non-starter as a builtin, but bash ships with an example
> `whatis' shell function that does this.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>

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

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:54                     ` Rob Pike
@ 2020-02-09  0:11                       ` Chet Ramey
  0 siblings, 0 replies; 61+ messages in thread
From: Chet Ramey @ 2020-02-09  0:11 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

On 2/8/20 6:54 PM, Rob Pike wrote:
> Well, "whatis" was a fine starter in 1983.

At which point the name had been in use for something else for four
years. The name is the problem, not the function.

> 
> I'm not saying anything should change. This is a history list.

Sure. The question is whether you can get what you want today.

-- 
``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] 61+ messages in thread

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 23:29                 ` Rob Pike
  2020-02-08 23:35                   ` Warner Losh
  2020-02-08 23:36                   ` Chet Ramey
@ 2020-02-09  0:19                   ` Larry McVoy
  2 siblings, 0 replies; 61+ messages in thread
From: Larry McVoy @ 2020-02-09  0:19 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

> In today's Unix (I use the term loosely) world, the phrase "free of
> decoration" is apostasy.

Yeah, it's annoying.  When I was building my last big system (BitKeeper)
I "solved" the problem by having -s (silent) as an option to pretty much
every command that produced output.

In terms of controlling output, we took the SCCS keywords on steriods,
we evolved it to sort of a little programming language.  I was told
that "bk changes" (think git log sort of) couldn't be taught to produce
JSON output.  Oh, it can't huh.  Below is the input that tells it to do
just that.  It's sort of awk like, control words are $word,  "quoted stuff
is printed, :THING: means print whatever THING is, variables are $0 .. $9
and eval to "" or 0 in numerical context.  The main body script, much like
awk calls it on each line, the script is called on each commit (and it 
optionally recurses into files as well).  I'm pretty proud of it, it
works really, really well.

$ cat `bk bin`/dspec-changes-json
# dspec-v2
# The default dspec used by 'bk changes -json'

$begin {
	"[\n"
}

$if (:CHANGESET: && !:COMPONENT_V:) {
	$if($0 -eq 1) {
		"\},\n"
	}
	"\{\n"
	"  \"key\": \":MD5KEY:\",\n"
	"  \"user\": \":USER:\",\n"
	"  \"host\": \":HOST:\",\n"
	"  \"date\": \":Dy:-:Dm:-:Dd:T:T::TZ:\",\n"
	"  \"serial\": :DS:,\n"
	"  \"comments\": \"" $each(:C:){$json{(:C:)}\\n} "\",\n"
        $if (:TAGS:) {
             "  \"tags\": [ "
             $each(:TAGS:){:JOIN:"\""(:TAGS:)"\""}
             " ],\n"
        }
        "  \"parents\": [ "
            $if(:PARENT:){"\"" :MD5KEY|PARENT: "\""}
            $if(:PARENT: && :MPARENT:){," "}
            $if(:MPARENT:){"\"" :MD5KEY|MPARENT: "\""}
            " ]\n"
	${0=1}		 		# we need to close off the changeset
}

$end {
	$if($0 -eq 1) {
		"\}\n"
	}
	"]\n"
}

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 21:50     ` Rob Pike
  2020-02-08 22:29       ` Chet Ramey
  2020-02-08 22:31       ` Richard Salz
@ 2020-02-10 13:18       ` Tony Finch
  2020-02-10 15:05       ` Dan Cross
  3 siblings, 0 replies; 61+ messages in thread
From: Tony Finch @ 2020-02-10 13:18 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

Rob Pike <robpike@gmail.com> wrote:
>
> Unfortunately, Steve's memory allocation trick, mallocking on faults, isn't
> portable, and I suspect the code will never run on a modern OS.

I heard that one of the first things that each of the various 68000 ports
had to do was patch the shell to make its memory allocation less
adventurous.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Sole, Lundy, Fastnet: West 7 to severe gale 9, occasionally storm 10 at first.
High or very high. Squally showers, thundery for a time. Moderate,
occasionally poor.

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

* Re: [TUHS] Warner's Early Unix Presentation
  2020-02-08 21:50     ` Rob Pike
                         ` (2 preceding siblings ...)
  2020-02-10 13:18       ` Tony Finch
@ 2020-02-10 15:05       ` Dan Cross
  2020-02-10 15:46         ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] arnold
  3 siblings, 1 reply; 61+ messages in thread
From: Dan Cross @ 2020-02-10 15:05 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

On Sat, Feb 8, 2020 at 4:52 PM Rob Pike <robpike@gmail.com> wrote:

> [snip] I still think it's a great piece of code, and I miss the v8 shell
> every day. [snip]


> Unfortunately, Steve's memory allocation trick, mallocking on faults,
> isn't portable, and I suspect the code will never run on a modern OS. Tom
> Duff's rc was done as a reaction to the shell being, despite its other
> glories, still a macro language. But that's another story.
>

Geoff Collyer wrote a nice paper about experiences porting the 9th Edition
shell to SunOS 3 on the 68k some years ago.
http://www.collyer.net/who/geoff/sh.tour.pdf

There is a copy of source code on his personal web page:
http://www.collyer.net/who/geoff/

I wonder if any of the 8th edition shell changes you mentioned survived in
that code?

        - Dan C.

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

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

* [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-10 15:05       ` Dan Cross
@ 2020-02-10 15:46         ` arnold
  2020-02-10 18:39           ` Rob Pike
  0 siblings, 1 reply; 61+ messages in thread
From: arnold @ 2020-02-10 15:46 UTC (permalink / raw)
  To: robpike, crossd; +Cc: tuhs

Dan Cross <crossd@gmail.com> wrote:

> Geoff Collyer wrote a nice paper about experiences porting the 9th Edition
> shell to SunOS 3 on the 68k some years ago.
> http://www.collyer.net/who/geoff/sh.tour.pdf
>
> There is a copy of source code on his personal web page:
> http://www.collyer.net/who/geoff/
>
> I wonder if any of the 8th edition shell changes you mentioned survived in
> that code?

It took less than 10 minutes to get it to compile under Linux. 'whatis'
is there, although the pretty printing of function code leaves
much to be desired.

Lacking is both readline and job control.

Arnold

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-10 15:46         ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] arnold
@ 2020-02-10 18:39           ` Rob Pike
  2020-02-10 18:59             ` Bakul Shah
                               ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-10 18:39 UTC (permalink / raw)
  To: arnold; +Cc: The Eunuchs Hysterical Society

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

Readline and job control were less compelling when you had multiple command
windows of editable typescript, which we all had with the Blit.

-rob


On Tue, Feb 11, 2020 at 2:46 AM <arnold@skeeve.com> wrote:

> Dan Cross <crossd@gmail.com> wrote:
>
> > Geoff Collyer wrote a nice paper about experiences porting the 9th
> Edition
> > shell to SunOS 3 on the 68k some years ago.
> > http://www.collyer.net/who/geoff/sh.tour.pdf
> >
> > There is a copy of source code on his personal web page:
> > http://www.collyer.net/who/geoff/
> >
> > I wonder if any of the 8th edition shell changes you mentioned survived
> in
> > that code?
>
> It took less than 10 minutes to get it to compile under Linux. 'whatis'
> is there, although the pretty printing of function code leaves
> much to be desired.
>
> Lacking is both readline and job control.
>
> Arnold
>

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-10 18:39           ` Rob Pike
@ 2020-02-10 18:59             ` Bakul Shah
  2020-02-10 19:58             ` Angelo Papenhoff
  2020-02-11  9:33             ` arnold
  2 siblings, 0 replies; 61+ messages in thread
From: Bakul Shah @ 2020-02-10 18:59 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Tue, 11 Feb 2020 05:39:26 +1100 Rob Pike <robpike@gmail.com> wrote:
>
> Readline and job control were less compelling when you had multiple command
> windows of editable typescript, which we all had with the Blit.

^Z is still useful, to stop forward progress temporarily.
Analogous to what ^S/^Q does for output stream.

As for editable typescript, I like how Dyalog's APL console
app works. You can edit any previous expression but when you
run it, the original expression is restored and the edited
expression appears on a new line. This way you can see the
real history of what you did, as opposed to in acme or rio,
for example, where the original content of edited lines in an
rc shell window is lost.

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-10 18:39           ` Rob Pike
  2020-02-10 18:59             ` Bakul Shah
@ 2020-02-10 19:58             ` Angelo Papenhoff
  2020-02-10 20:11               ` Chet Ramey
  2020-02-11  9:33             ` arnold
  2 siblings, 1 reply; 61+ messages in thread
From: Angelo Papenhoff @ 2020-02-10 19:58 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On 11/02/20, Rob Pike wrote:
> Readline and job control were less compelling when you had multiple command
> windows of editable typescript, which we all had with the Blit.

What i like is the autocorrect feature in v8:

$ cd /usr/blot
/usr/blit
$ pwd
/usr/blit


aap

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-10 19:58             ` Angelo Papenhoff
@ 2020-02-10 20:11               ` Chet Ramey
  0 siblings, 0 replies; 61+ messages in thread
From: Chet Ramey @ 2020-02-10 20:11 UTC (permalink / raw)
  To: Angelo Papenhoff, The Eunuchs Hysterical Society

On 2/10/20 2:58 PM, Angelo Papenhoff wrote:
> On 11/02/20, Rob Pike wrote:
>> Readline and job control were less compelling when you had multiple command
>> windows of editable typescript, which we all had with the Blit.
> 
> What i like is the autocorrect feature in v8:
> 
> $ cd /usr/blot
> /usr/blit
> $ pwd
> /usr/blit

Maybe unsurprisingly, bash has that as well (the `cdspell' option). I
picked up a fair amount from the v8/v9 shells.

-- 
``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] 61+ messages in thread

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-10 18:39           ` Rob Pike
  2020-02-10 18:59             ` Bakul Shah
  2020-02-10 19:58             ` Angelo Papenhoff
@ 2020-02-11  9:33             ` arnold
  2020-02-11  9:47               ` Noel Hunt
  2020-02-11  9:47               ` Rob Pike
  2 siblings, 2 replies; 61+ messages in thread
From: arnold @ 2020-02-11  9:33 UTC (permalink / raw)
  To: robpike, arnold; +Cc: tuhs

Rob Pike <robpike@gmail.com> wrote:

> Readline and job control were less compelling when you had multiple command
> windows of editable typescript, which we all had with the Blit.

Understandable. But the 99.9999% of us not in 1127 only had glass ttys.

I did have a DMD 5620 for a while (which I loved), but I don't recall
that it had editiable typescripts.  I thought that that came in
with 8-1/2 in Plan 9?

Thanks,

Arnold

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11  9:33             ` arnold
@ 2020-02-11  9:47               ` Noel Hunt
  2020-02-11  9:47               ` Rob Pike
  1 sibling, 0 replies; 61+ messages in thread
From: Noel Hunt @ 2020-02-11  9:47 UTC (permalink / raw)
  To: arnold; +Cc: The Eunuchs Hysterical Society

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

2020年2月11日(火) 18:34 <arnold@skeeve.com>:

> I did have a DMD 5620 for a while (which I loved), but I don't recall
> that it had editiable typescripts.  I thought that that came in
> with 8-1/2 in Plan 9?
>

Muxterm, the default user-interface window under mux, was most
definitely editable.

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

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  9:33             ` arnold
  2020-02-11  9:47               ` Noel Hunt
@ 2020-02-11  9:47               ` Rob Pike
  2020-02-11  9:59                 ` Rob Pike
  1 sibling, 1 reply; 61+ messages in thread
From: Rob Pike @ 2020-02-11  9:47 UTC (permalink / raw)
  To: arnold; +Cc: The Eunuchs Hysterical Society

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

There were three window systems that I know of that ran on the various
incarnations of that machine. The first, mpx, was very basic. The second,
mux, allowed editing of text on the screen and had some interesting
properties, such as "hold mode", which stopped all reads to the host until
hold mode was cancelled. This allowed one to use the terminal window as a
general text editor for any application, and was obviously an influence on
various followons. It also didn't satisfy any read to the host until you
hit return, so all hold mode did was make its basic one-line operation
multiline, but it felt liberating and was used constantly for writing mail
messages and so on.

Both these systems depended (eventually) on new v8 stuff like streams and
select, so they didn't work on System 3 etc. USG did a thing for themselves
called layers, which was more like mpx than mux.

-rob


On Tue, Feb 11, 2020 at 8:33 PM <arnold@skeeve.com> wrote:

> Rob Pike <robpike@gmail.com> wrote:
>
> > Readline and job control were less compelling when you had multiple
> command
> > windows of editable typescript, which we all had with the Blit.
>
> Understandable. But the 99.9999% of us not in 1127 only had glass ttys.
>
> I did have a DMD 5620 for a while (which I loved), but I don't recall
> that it had editiable typescripts.  I thought that that came in
> with 8-1/2 in Plan 9?
>
> Thanks,
>
> Arnold
>

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

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  9:47               ` Rob Pike
@ 2020-02-11  9:59                 ` Rob Pike
  2020-02-11 17:05                   ` Steffen Nurpmeso
                                     ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-11  9:59 UTC (permalink / raw)
  To: arnold; +Cc: The Eunuchs Hysterical Society

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

My general mood about the current standard way of nerd working is how
unimaginative and old-fashioned it feels. There are countless ways we could
be interacting with our terminals, editors, and shells while we program,
but for various sociological and historical reasons we're pretty much using
one from decades ago. I'm sure it's productive for almost everyone, but it
seems dull to me. We could be doing something much more dynamic. I mean,
xterm is hardly more sophisticated than the lame terminal code that ran in
mpx (ca. 1982), other than colors and cursor addressing, which date from
the 1960s via early PCs. IDEs don't sing to me, although they are powerful,
because they don't integrate well with the environment, only with the
language. And they are just lots of features, not a coherent vision. No
model to speak of.

Compare what happened with our shell windows with what happened with our
"smart" phones in the last 20 years and you'll get some inkling of what I
think we're missing. It's not that we should program the way we use
iPhones, but that there are fields where user interface work has made a
real different recently. Not so in programming, though. We're missing out.

But I'm a grumpy old man and getting far off topic. Warren should cry,
"enough!".

-rob

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

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  9:59                 ` Rob Pike
@ 2020-02-11 17:05                   ` Steffen Nurpmeso
  2020-02-11 17:18                     ` Arthur Krewat
                                       ` (2 more replies)
  2020-02-11 17:36                   ` Dan Cross
  2020-02-11 18:35                   ` Christopher Browne
  2 siblings, 3 replies; 61+ messages in thread
From: Steffen Nurpmeso @ 2020-02-11 17:05 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

Rob Pike wrote in
<CAKzdPgz6qPuqOfTe4eLqmM4f4RXTxqWRO-3NLHTaMxJg7mT-Nw@mail.gmail.com>:
 |My general mood about the current standard way of nerd working is how \
 |unimaginative and old-fashioned it feels. There are countless ways \
 |we could be interacting with our terminals, editors, and shells 
 |while we program, but for various sociological and historical reasons \
 |we're pretty much using one from decades ago. I'm sure it's productive \
 |for almost everyone, but it seems dull to me. We could be 
 |doing something much more dynamic. I mean, xterm is hardly more sophisti\
 |cated than the lame terminal code that ran in mpx (ca. 1982), other \
 |than colors and cursor addressing, which date from the 1960s 
 |via early PCs. IDEs don't sing to me, although they are powerful, because \
 |they don't integrate well with the environment, only with the language. \
 |And they are just lots of features, not a coherent 
 |vision. No model to speak of.
 |
 |Compare what happened with our shell windows with what happened with \
 |our "smart" phones in the last 20 years and you'll get some inkling \
 |of what I think we're missing. It's not that we should program the 
 |way we use iPhones, but that there are fields where user interface \
 |work has made a real different recently. Not so in programming, though. \
 |We're missing out.

I cannot imagine any other real step forward but control-by-
thought, aka brain computer interfaces.  (I personally am even
convinced we will get the brain implant -- ever since i got all
those B and C Hollywood movies from the 50s wrong, back when i was
a kid.  It is convincing still, automatic emergency calls, health
record and cases of incompatibility at hand when needed, and not
to talk about the hints it will give the law enforcement side of
the road.)

Just last year i have seen a report on the current stage of
affairs, Carnegie-Mellon and Minnesota Universities seem to have
build a non-invasively controlled robotic arm, pretty high
precision.

  "Wir haben erhebliche Fortschritte im Bereich
  Robotervorrichtungen mit Gedankensteuerung über Gehirnimplantate
  gemacht.
  We have made substantial progress in the region of
  thought-controlled robotic devices via implants.

  Das ist hervorragende Forschungsarbeit", sagt He.
  "That is superb research work", says He [Professor Bin He,
  Carnegie-Mellon].

  "Nichtinvasiv ist jedoch unser ultimatives Ziel.
  Fortschritte in der neuronalen Dekodierung und der praktischen
  Auswirkungen auf die mögliche Entwicklung nichtinvasiver
  Nutzbarkeit nichtinvasiver Roboterarmsteuerung werden erhebliche
  Neurorobotik haben."

  "Albeit non-invasive is our ultimate goal.
  Progress in neuronal decoding, and the practical usability of
  non-invasive control of robotic arms will have substantial
  effect on the possible development of non-invasive
  neuro-robotics."

 |But I'm a grumpy old man and getting far off topic. Warren should cry, \
 |"enough!".

I personally would love it, if it where only in the hands of
empathic beings, capable of reflection.  Yet it is us. ^_^

--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] 61+ messages in thread

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 17:05                   ` Steffen Nurpmeso
@ 2020-02-11 17:18                     ` Arthur Krewat
  2020-02-11 18:22                     ` Kurt H Maier
  2020-02-11 18:26                     ` Jon Steinhart
  2 siblings, 0 replies; 61+ messages in thread
From: Arthur Krewat @ 2020-02-11 17:18 UTC (permalink / raw)
  To: tuhs

Sorry to top-post...

To me, the biggest handicap to getting anything done, code-wise, 
command-line-wise, basically anything, is the keyboard/mouse.

I use keyboard shortcuts as much as possible, being an old LA36 kind 
guy, but I would love to have something that just by looking at text, be 
able to highlight, copy/cut/paste, etc.

Even action buttons. It would be great to look at the "Send" button in 
Thunderbird and press a key on the mouse or keyboard (or some other 
eye-contact type signal) and "do" it.

Was anything ever done in terms of sub-vocalization? Lots of stories in 
Sci-Fi about that, nothing ever came out of it, I don't think.


On 2/11/2020 12:05 PM, Steffen Nurpmeso wrote:
> Rob Pike wrote in
> <CAKzdPgz6qPuqOfTe4eLqmM4f4RXTxqWRO-3NLHTaMxJg7mT-Nw@mail.gmail.com>:
>   |My general mood about the current standard way of nerd working is how \
>   |unimaginative and old-fashioned it feels. There are countless ways \
>   |we could be interacting with our terminals, editors, and shells
>   |while we program, but for various sociological and historical reasons \
>   |we're pretty much using one from decades ago. I'm sure it's productive \
>   |for almost everyone, but it seems dull to me. We could be
>   |doing something much more dynamic. I mean, xterm is hardly more sophisti\
>   |cated than the lame terminal code that ran in mpx (ca. 1982), other \
>   |than colors and cursor addressing, which date from the 1960s
>   |via early PCs. IDEs don't sing to me, although they are powerful, because \
>   |they don't integrate well with the environment, only with the language. \
>   |And they are just lots of features, not a coherent
>   |vision. No model to speak of.
>   |
>   |Compare what happened with our shell windows with what happened with \
>   |our "smart" phones in the last 20 years and you'll get some inkling \
>   |of what I think we're missing. It's not that we should program the
>   |way we use iPhones, but that there are fields where user interface \
>   |work has made a real different recently. Not so in programming, though. \
>   |We're missing out.
>
> I cannot imagine any other real step forward but control-by-
> thought, aka brain computer interfaces.  (I personally am even
> convinced we will get the brain implant -- ever since i got all
> those B and C Hollywood movies from the 50s wrong, back when i was
> a kid.  It is convincing still, automatic emergency calls, health
> record and cases of incompatibility at hand when needed, and not
> to talk about the hints it will give the law enforcement side of
> the road.)
>
> Just last year i have seen a report on the current stage of
> affairs, Carnegie-Mellon and Minnesota Universities seem to have
> build a non-invasively controlled robotic arm, pretty high
> precision.
>
>    "Wir haben erhebliche Fortschritte im Bereich
>    Robotervorrichtungen mit Gedankensteuerung über Gehirnimplantate
>    gemacht.
>    We have made substantial progress in the region of
>    thought-controlled robotic devices via implants.
>
>    Das ist hervorragende Forschungsarbeit", sagt He.
>    "That is superb research work", says He [Professor Bin He,
>    Carnegie-Mellon].
>
>    "Nichtinvasiv ist jedoch unser ultimatives Ziel.
>    Fortschritte in der neuronalen Dekodierung und der praktischen
>    Auswirkungen auf die mögliche Entwicklung nichtinvasiver
>    Nutzbarkeit nichtinvasiver Roboterarmsteuerung werden erhebliche
>    Neurorobotik haben."
>
>    "Albeit non-invasive is our ultimate goal.
>    Progress in neuronal decoding, and the practical usability of
>    non-invasive control of robotic arms will have substantial
>    effect on the possible development of non-invasive
>    neuro-robotics."
>
>   |But I'm a grumpy old man and getting far off topic. Warren should cry, \
>   |"enough!".
>
> I personally would love it, if it where only in the hands of
> empathic beings, capable of reflection.  Yet it is us. ^_^
>
> --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] 61+ messages in thread

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  9:59                 ` Rob Pike
  2020-02-11 17:05                   ` Steffen Nurpmeso
@ 2020-02-11 17:36                   ` Dan Cross
  2020-02-11 18:35                   ` Christopher Browne
  2 siblings, 0 replies; 61+ messages in thread
From: Dan Cross @ 2020-02-11 17:36 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

On Tue, Feb 11, 2020 at 4:59 AM Rob Pike <robpike@gmail.com> wrote:

> My general mood about the current standard way of nerd working is how
> unimaginative and old-fashioned it feels. There are countless ways we could
> be interacting with our terminals, editors, and shells while we program,
> but for various sociological and historical reasons we're pretty much using
> one from decades ago. I'm sure it's productive for almost everyone, but it
> seems dull to me. We could be doing something much more dynamic. I mean,
> xterm is hardly more sophisticated than the lame terminal code that ran in
> mpx (ca. 1982), other than colors and cursor addressing, which date from
> the 1960s via early PCs. IDEs don't sing to me, although they are powerful,
> because they don't integrate well with the environment, only with the
> language. And they are just lots of features, not a coherent vision. No
> model to speak of.
>

> Compare what happened with our shell windows with what happened with our
> "smart" phones in the last 20 years and you'll get some inkling of what I
> think we're missing. It's not that we should program the way we use
> iPhones, but that there are fields where user interface work has made a
> real different recently. Not so in programming, though. We're missing out.
>

What do you think of thinks like Jupyter or Lighttable?  The early demos
for the latter, I thought, were particularly compelling (though sadly the
current implementation seems like much more of a traditional text editor
and far removed from the original vision). Compare
https://www.youtube.com/watch?v=H58-n7uldoU to
www.youtube.com/watch?v=52SVAMM3V78

But I'm a grumpy old man and getting far off topic. Warren should cry,
> "enough!".
>

One of the reasons we study history is to understand the present and inform
our decisions for the future. Personally, I enjoy these sorts of
explorations of where we might have done things differently.

        - Dan C.

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

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11 17:05                   ` Steffen Nurpmeso
  2020-02-11 17:18                     ` Arthur Krewat
@ 2020-02-11 18:22                     ` Kurt H Maier
  2020-02-16 21:34                       ` Wesley Parish
  2020-02-11 18:26                     ` Jon Steinhart
  2 siblings, 1 reply; 61+ messages in thread
From: Kurt H Maier @ 2020-02-11 18:22 UTC (permalink / raw)
  To: tuhs

On Tue, Feb 11, 2020 at 06:05:01PM +0100, Steffen Nurpmeso wrote:
> 
> I cannot imagine any other real step forward but control-by-
> thought, aka brain computer interfaces. 

I can't even trust computers to do the right thing with input specially
crafted for the program I'm using.  There is no way in hell I'm turning
it loose on a direct neural interface.  Software engineering, as a
discipline, is going to require a lot more actual discipline before 
neural interfaces become anything but fuel for a dystopian hellscape.

I'm not saying we can't get there.  I'm saying we're not headed in that
direction so far.

khm

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 17:05                   ` Steffen Nurpmeso
  2020-02-11 17:18                     ` Arthur Krewat
  2020-02-11 18:22                     ` Kurt H Maier
@ 2020-02-11 18:26                     ` Jon Steinhart
  2020-02-11 23:56                       ` Steffen Nurpmeso
  2 siblings, 1 reply; 61+ messages in thread
From: Jon Steinhart @ 2020-02-11 18:26 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Steffen Nurpmeso writes:
> Rob Pike wrote in
> <CAKzdPgz6qPuqOfTe4eLqmM4f4RXTxqWRO-3NLHTaMxJg7mT-Nw@mail.gmail.com>:
>  |My general mood about the current standard way of nerd working is how \
>  |unimaginative and old-fashioned it feels. There are countless ways \
>  |we could be interacting with our terminals, editors, and shells 
>  |while we program, but for various sociological and historical reasons \
>  |we're pretty much using one from decades ago. I'm sure it's productive \
>  |for almost everyone, but it seems dull to me. We could be 
>  |doing something much more dynamic. I mean, xterm is hardly more sophisti\
>  |cated than the lame terminal code that ran in mpx (ca. 1982), other \
>  |than colors and cursor addressing, which date from the 1960s 
>  |via early PCs. IDEs don't sing to me, although they are powerful, because \
>  |they don't integrate well with the environment, only with the language. \
>  |And they are just lots of features, not a coherent 
>  |vision. No model to speak of.
>  |
>  |Compare what happened with our shell windows with what happened with \
>  |our "smart" phones in the last 20 years and you'll get some inkling \
>  |of what I think we're missing. It's not that we should program the 
>  |way we use iPhones, but that there are fields where user interface \
>  |work has made a real different recently. Not so in programming, though. \
>  |We're missing out.
>
> I cannot imagine any other real step forward but control-by-
> thought, aka brain computer interfaces.  (I personally am even
> convinced we will get the brain implant -- ever since i got all
> those B and C Hollywood movies from the 50s wrong, back when i was
> a kid.  It is convincing still, automatic emergency calls, health
> record and cases of incompatibility at hand when needed, and not
> to talk about the hints it will give the law enforcement side of
> the road.)
>
> Just last year i have seen a report on the current stage of
> affairs, Carnegie-Mellon and Minnesota Universities seem to have
> build a non-invasively controlled robotic arm, pretty high
> precision.
>
>   "Wir haben erhebliche Fortschritte im Bereich
>   Robotervorrichtungen mit Gedankensteuerung über Gehirnimplantate
>   gemacht.
>   We have made substantial progress in the region of
>   thought-controlled robotic devices via implants.
>
>   Das ist hervorragende Forschungsarbeit", sagt He.
>   "That is superb research work", says He [Professor Bin He,
>   Carnegie-Mellon].
>
>   "Nichtinvasiv ist jedoch unser ultimatives Ziel.
>   Fortschritte in der neuronalen Dekodierung und der praktischen
>   Auswirkungen auf die mögliche Entwicklung nichtinvasiver
>   Nutzbarkeit nichtinvasiver Roboterarmsteuerung werden erhebliche
>   Neurorobotik haben."
>
>   "Albeit non-invasive is our ultimate goal.
>   Progress in neuronal decoding, and the practical usability of
>   non-invasive control of robotic arms will have substantial
>   effect on the possible development of non-invasive
>   neuro-robotics."
>
>  |But I'm a grumpy old man and getting far off topic. Warren should cry, \
>  |"enough!".
>
> I personally would love it, if it where only in the hands of
> empathic beings, capable of reflection.  Yet it is us. ^_^
>
> --steffen

Well, I'm gonna give my two cents on this before Warren tells us that it's off-topic :-)

One way to look at it is that there are two stages to programming or any
other problem-solving discipline.  First, clearly express the problem.
Second, implement a solution.

There's been a lot of improvement in both of these areas during my lifetime.

Especially when I look at the "everybody must learn to code" movement I see
people looking for a magic bullet; they just want to think of something and
have it magically appear.  Problem is that the thinking of something isn't
that easy.  People want DWIT (do what I think), a step beyond DWIM :-)

I'm reminded of the awful virtual reality panel at SIGGRAPH some decades ago
now where people stood up and said "with virtual reality there will be no
misunderstanding and people will be able to know exactly what you're thinking."
My response was "wow, if people knew exactly what you were thinking they'd kill
you."  The fuzziness of our brains is an asset here, not a liability.  So I'm
not thinking that translating thoughts directly into programs is a good thing.

All that said, there is an area that I think needs some work, which reminds me
that I wrote Tamara Munzner at UBC about this and need to ping her again.  My
current troublemaking project is to make an unfortunately necessary change to
linux to accomplish something that I want to do.  Because I haven't mucked
around in the kernel before I've been keeping notes as I try to figure it out;
sort of a travelogue.

One of the things that's important to me is writing code for the reader, not
the writer.  Being old, I remember working for companies where there was
warranty support for products, and that maintenance and support cost way more
than development.  So I've always written code for the maintainers because I
never wanted to become one because nobody could figure out my code.

Oh, Jon's rambling here, how is this relevant?  Something that I never gave
much thought about until I was a reviewer for Tamara's book is that my coding
style tries to maximize the brain's pre-attentive mode.  A lot of hunting
around in code involves visually scanning for patterns (vgrep), and one would
like to be able to do that in fixed time as opposed to linear time.

In my opinion, the linux code sucks at this.  The coding style of breaking up
functions to keep the number of indent levels low has what I'm calling poor
"meatspace locality of reference."  People have caches too, and we'd never
write code for a computer that thrashes as badly as code written for people.

Anyway, what I've been wondering about is whether anybody has examined the
UIs of different IDEs from a pre-attentive standpoint.  One of the weird
things about how our brains manage pre-attentive mode is that there are only
a handful of things that we can do in that mode before popping out, and that
those things have weird interactions.  So, for example, does coloring things
work?  Does bracket matching work?  Do they still work if you do both?  A
good thesis topic for someone younger than me.

Jon

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11  9:59                 ` Rob Pike
  2020-02-11 17:05                   ` Steffen Nurpmeso
  2020-02-11 17:36                   ` Dan Cross
@ 2020-02-11 18:35                   ` Christopher Browne
  2020-02-11 18:54                     ` Rob Pike
  2020-02-11 21:36                     ` Harald Arnesen
  2 siblings, 2 replies; 61+ messages in thread
From: Christopher Browne @ 2020-02-11 18:35 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

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

On Tue, 11 Feb 2020 at 05:00, Rob Pike <robpike@gmail.com> wrote:

> My general mood about the current standard way of nerd working is how
> unimaginative and old-fashioned it feels. There are countless ways we could
> be interacting with our terminals, editors, and shells while we program,
> but for various sociological and historical reasons we're pretty much using
> one from decades ago. I'm sure it's productive for almost everyone, but it
> seems dull to me. We could be doing something much more dynamic. I mean,
> xterm is hardly more sophisticated than the lame terminal code that ran in
> mpx (ca. 1982), other than colors and cursor addressing, which date from
> the 1960s via early PCs. IDEs don't sing to me, although they are powerful,
> because they don't integrate well with the environment, only with the
> language. And they are just lots of features, not a coherent vision. No
> model to speak of.
>
> Compare what happened with our shell windows with what happened with our
> "smart" phones in the last 20 years and you'll get some inkling of what I
> think we're missing. It's not that we should program the way we use
> iPhones, but that there are fields where user interface work has made a
> real different recently. Not so in programming, though. We're missing out.
>
> But I'm a grumpy old man and getting far off topic. Warren should cry,
> "enough!".
>

I recently saw indication that the UI for Sam and Acme were inspired by
Oberon.  (And per url [1] below, Rob Pike is quoted, sort of...)

I'd be interested (and I think that's a TUHS thing ;-) ) in hearing some
elaboration on that.  All that is said is that "Rob was blown away" and
that this "influenced" Sam/Acme; is there some further explanation of that
worth pointing at?  (Or are some Oberon fans putting words in mouths?  ;-) )

[1] https://lists.inf.ethz.ch/pipermail/oberon/2011/006245.html
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 18:35                   ` Christopher Browne
@ 2020-02-11 18:54                     ` Rob Pike
  2020-02-11 21:36                     ` Harald Arnesen
  1 sibling, 0 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-11 18:54 UTC (permalink / raw)
  To: Christopher Browne; +Cc: The Eunuchs Hysterical Society

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

Acme was definitely inspired by Oberon the system. I visited ETH a number
of times in the '80s and there were some properties of Oberon I found
attractive. Acme definitely grew out of thinking I did there, but of course
it was not tied to any language (unlike Oberon or an IDE), but rather
integrated the Plan 9 command environment. Also, the button 3
context-getting thing was completely new, and when I spoke at ETH later
about Acme, Wirth singled out that feature as something of interest.

Sam predates all that.

-rob


On Wed, Feb 12, 2020 at 5:35 AM Christopher Browne <cbbrowne@gmail.com>
wrote:

> On Tue, 11 Feb 2020 at 05:00, Rob Pike <robpike@gmail.com> wrote:
>
>> My general mood about the current standard way of nerd working is how
>> unimaginative and old-fashioned it feels. There are countless ways we could
>> be interacting with our terminals, editors, and shells while we program,
>> but for various sociological and historical reasons we're pretty much using
>> one from decades ago. I'm sure it's productive for almost everyone, but it
>> seems dull to me. We could be doing something much more dynamic. I mean,
>> xterm is hardly more sophisticated than the lame terminal code that ran in
>> mpx (ca. 1982), other than colors and cursor addressing, which date from
>> the 1960s via early PCs. IDEs don't sing to me, although they are powerful,
>> because they don't integrate well with the environment, only with the
>> language. And they are just lots of features, not a coherent vision. No
>> model to speak of.
>>
>> Compare what happened with our shell windows with what happened with our
>> "smart" phones in the last 20 years and you'll get some inkling of what I
>> think we're missing. It's not that we should program the way we use
>> iPhones, but that there are fields where user interface work has made a
>> real different recently. Not so in programming, though. We're missing out.
>>
>> But I'm a grumpy old man and getting far off topic. Warren should cry,
>> "enough!".
>>
>
> I recently saw indication that the UI for Sam and Acme were inspired by
> Oberon.  (And per url [1] below, Rob Pike is quoted, sort of...)
>
> I'd be interested (and I think that's a TUHS thing ;-) ) in hearing some
> elaboration on that.  All that is said is that "Rob was blown away" and
> that this "influenced" Sam/Acme; is there some further explanation of that
> worth pointing at?  (Or are some Oberon fans putting words in mouths?  ;-) )
>
> [1] https://lists.inf.ethz.ch/pipermail/oberon/2011/006245.html
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
>

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 18:35                   ` Christopher Browne
  2020-02-11 18:54                     ` Rob Pike
@ 2020-02-11 21:36                     ` Harald Arnesen
  1 sibling, 0 replies; 61+ messages in thread
From: Harald Arnesen @ 2020-02-11 21:36 UTC (permalink / raw)
  To: tuhs

Christopher Browne [11/02/2020 19.35]:

> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"

I wqould ask: "How would MacGyver handle this?".
-- 
Hilsen Harald

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 18:26                     ` Jon Steinhart
@ 2020-02-11 23:56                       ` Steffen Nurpmeso
  2020-02-12  0:12                         ` Jon Steinhart
  0 siblings, 1 reply; 61+ messages in thread
From: Steffen Nurpmeso @ 2020-02-11 23:56 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

Jon Steinhart wrote in
<202002111826.01BIQp2A1764361@darkstar.fourwinds.com>:
 |Steffen Nurpmeso writes:
 |> Rob Pike wrote in
 |> <CAKzdPgz6qPuqOfTe4eLqmM4f4RXTxqWRO-3NLHTaMxJg7mT-Nw@mail.gmail.com>:
 |>|My general mood about the current standard way of nerd working is how \
 |>|unimaginative and old-fashioned it feels. There are countless ways \
 |>|we could be interacting with our terminals, editors, and shells 
 |>|while we program, but for various sociological and historical reasons \
 |>|we're pretty much using one from decades ago. I'm sure it's productive \
 |>|for almost everyone, but it seems dull to me. We could be 
 |>|doing something much more dynamic. I mean, xterm is hardly more sophisti\
 |>|cated than the lame terminal code that ran in mpx (ca. 1982), other \
 |>|than colors and cursor addressing, which date from the 1960s 
 |>|via early PCs. IDEs don't sing to me, although they are powerful, \
 |>|because \
 |>|they don't integrate well with the environment, only with the language. \
 |>|And they are just lots of features, not a coherent 
 |>|vision. No model to speak of.
 ...
 |> I cannot imagine any other real step forward but control-by-
 |> thought, aka brain computer interfaces.  (I personally am even
 ...
 |> Just last year i have seen a report on the current stage of
 |> affairs, Carnegie-Mellon and Minnesota Universities seem to have
 |> build a non-invasively controlled robotic arm, pretty high
 |> precision.
 ...

 |One way to look at it is that there are two stages to programming or any
 |other problem-solving discipline.  First, clearly express the problem.
 |Second, implement a solution.

I was impressed what Steve Johnson said at the Unix 50
celebration, about that AI program which learned a game from
scratch in a few hours, just by interpreting "the pixels" that the
game produces on the screen ... and became better than every human
being.

 |There's been a lot of improvement in both of these areas during my \
 |lifetime.
 |
 |Especially when I look at the "everybody must learn to code" movement I see
 |people looking for a magic bullet; they just want to think of something and
 |have it magically appear.  Problem is that the thinking of something isn't
 |that easy.  People want DWIT (do what I think), a step beyond DWIM :-)

Maybe visualized impressions will be interpretable at one time.
If i approach an "Oracle of Delphi" mind state with a "clear"
picture of where i want to go to, where i want the entire thing to
end up with, then i write good code.  I had this not seldom when
i was younger .. but maybe i just should take long walks more
often again.  Freud did one every day.

Of course you are right, you will likely need to focus your mind,
and that requires an intellectual context, knowledge, to base
upon.  That requires many small learning steps, that surely will
not change.  In fact in the western world times to learn are much
too short in my opinion, the normal way of other cultures is
a flatter learning curve, which gives humans more time for personal
development.  The latter in theory, of course.  But an imbalance
of technical knowledge and development of a personal state of mind
results in things like "have it magically appear".

This is not what i mean.  I would rather like it like those magnet
paint tablets from the 70s, where you paint something and then,
swoosh, everything is clean and you start from scratch.  This is
nothing new, we had this in many Science-Fictions, but mostly with
speech interaction, like "no, stop, not that; back two steps" or
something like this.  But by thought.  I think it must be fun,
today you see all the people looking into their smartphone, then
you are surrounded by truly autistic persons!

 |I'm reminded of the awful virtual reality panel at SIGGRAPH some decades \
 |ago
 |now where people stood up and said "with virtual reality there will be no
 |misunderstanding and people will be able to know exactly what you're \
 |thinking."
 |My response was "wow, if people knew exactly what you were thinking \
 |they'd kill
 |you."  The fuzziness of our brains is an asset here, not a liability. \
 | So I'm
 |not thinking that translating thoughts directly into programs is a \
 |good thing.

Killing is a trigger for the human brain for sure.  Given the
substantial amount of thoughts which are put into first person
shooters, for the military and (other) young teenagers.
One must face that many, many brains not only have a deficit in
possible targets for thinking, but also lack the motivation or
overall interest in developing them.
Our educational system does not seem to be interested in
addressing this issue either.

 |All that said, there is an area that I think needs some work, which \
 |reminds me
 |that I wrote Tamara Munzner at UBC about this and need to ping her \
 |again.  My
 |current troublemaking project is to make an unfortunately necessary \
 |change to
 |linux to accomplish something that I want to do.  Because I haven't mucked
 |around in the kernel before I've been keeping notes as I try to figure \
 |it out;
 |sort of a travelogue.

Linux kernel, horrific.  I currently write an audio-CD access tool
for Linux (since cdparanoia and its successor cd-paranoia seem to
be broken, and whereas cd-info seems to be ok its tarball is about
30 MB, and i thought i can fit this in about 10 KB, and i do rely
on the kernel to drive /dev/cdrom for me, anyway, we are not in
the 90s or so), and i had to look into the kernel source to figure
out the actual limit, and why there is one, of the number of audio
frames i can read at once.  The good news: it is open source!
(One may not read more than a second at once.)

 |One of the things that's important to me is writing code for the reader, \
 |not
 |the writer.  Being old, I remember working for companies where there was
 |warranty support for products, and that maintenance and support cost \
 |way more
 |than development.  So I've always written code for the maintainers \
 |because I
 |never wanted to become one because nobody could figure out my code.

That is fantastic.  I absolutely agree, and how often have
i trapped myself because of missing comments, or non-talking
variable names.  It is all so logical and clear when you actually
write the thing down, you cannot imagine that you will be lost in
a forest in just a few months from now.  That is human brain pure.

 |Oh, Jon's rambling here, how is this relevant?  Something that I never gave
 |much thought about until I was a reviewer for Tamara's book is that \
 |my coding
 |style tries to maximize the brain's pre-attentive mode.  A lot of hunting
 |around in code involves visually scanning for patterns (vgrep), and \
 |one would
 |like to be able to do that in fixed time as opposed to linear time.
 |
 |In my opinion, the linux code sucks at this.  The coding style of breaking \
 |up
 |functions to keep the number of indent levels low has what I'm calling poor
 |"meatspace locality of reference."  People have caches too, and we'd never
 |write code for a computer that thrashes as badly as code written for \
 |people.

With the exception of some overall comment blocks at the beginning
of files, and from a very superficial point of view, i do agree.
It seems to be expected that you carefully grasp the entire code
context, so that the necessity for the rest has vanished by
itself.  I am not a kernel person, however.
But mind you, that is just how it is with Linux.  You do not even
get an acknowledgement if you report dramatical kernel bugs.
I think i reported four or five real in the ~9-10 months i now use
Linux on bare metal, iof which two/three would have been deadly in
earlier times (Linux kernel survives crashes of a thread).  I did
not get feedback for anything.  But two were fixed as time went
by, that is the good news.

 |Anyway, what I've been wondering about is whether anybody has examined the
 |UIs of different IDEs from a pre-attentive standpoint.  One of the weird
 |things about how our brains manage pre-attentive mode is that there \
 |are only
 |a handful of things that we can do in that mode before popping out, \
 |and that
 |those things have weird interactions.  So, for example, does coloring \
 |things
 |work?  Does bracket matching work?  Do they still work if you do both?  A
 |good thesis topic for someone younger than me.

Interesting.  I have bookmarked a presentation of her to look at
when i have free time/download again.  I would think substantial
amount of money has been pumped in this area, but i never cared.
I work best when i take a long walk in nature, and hope that i get
kissed by the muse. ^_^  Then come back with a "mind map" of what
there shall be.  And implement it pretty naked vim(1).  ^_^
It seems i do not do all that good enough today.

What i think is that having those new possibilities could possibly
attract more people.  There are so many techniques to train your
brain, to strengthen memory, for example, to memorize tremendous
amount of data somehow, for example by "placing the data on
a virtual walk through the flat", and similar techniques.  If
people had the option to use their very own imagination, and
having computers map that, i think that would be interesting.

So i think, whereas the actual diversity in between people is
pretty minor, all that software now offers are colour themes and
possibly 3-d effects and whatever, but that is all optics and has
nothing much to do with touching peoples individual "brain needs",
aka it does not reach into their inner world in order to, i just
read that nice american term last week, "milk the shit out of it".
^_^

--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] 61+ messages in thread

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 23:56                       ` Steffen Nurpmeso
@ 2020-02-12  0:12                         ` Jon Steinhart
  2020-02-12  1:03                           ` [TUHS] V9 shell Warren Toomey
  2020-02-12  5:54                           ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Rob Pike
  0 siblings, 2 replies; 61+ messages in thread
From: Jon Steinhart @ 2020-02-12  0:12 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Steffen Nurpmeso writes:
>
> Of course you are right, you will likely need to focus your mind,
> and that requires an intellectual context, knowledge, to base upon.

Interesting that you mention this as I'm about to leave for a multi-day
advanced yoga workshop.  One of the things that I like about yoga is that
you do have to learn to focus your mind, and it's amazingly difficult to
be focused on something as seemingly simple as standing up straight.  I
don't think that it's reasonable to expect people to be able to focus
without training.  Can you imagine if a computer tried to follow all of
your fleeting thoughts?

In some respects, this takes me back to the early days of speech recognition.
I remember people enthusiastically telling me how it would solve the problem
of repetitive stress injuries.  They were surprised when I pointed out that
most people who use their voice in their work actually take vocal training;
RSIs are not uncommon among performers.

So really, what problem are we trying to solve here?  I would claim that the
problem is signal-to-noise ratio degradation that's a result of too many
people "learning to code" who have never learned to think.  Much like I feel
that it became harder to find good music when MIDI was invented because there
was all of a sudden a lot more noise masquerading as music.

I'm reminded of a Usenix panel session that I moderated on the future of window
systems a long time ago.  Rob was on the panel as was some guy whose name I
can't remember from Silicon Graphics.  The highlight of the presentation was
when Robin asked the question "So, if I understand what the SGI person is saying,
it doesn't matter how ugly your shirt is, you can always cover it up with a nice
jacket...."  While she was asking the question Rob anticipated the rest of the
question and started unbuttoning his shirt.

So maybe I'm just an old-school minimalist, but I think that the biggest problem
that needs solving is good low-level abstractions that are simple and work and
don't have to be papered over with layer upon layer on top of them.  I just find
myself without the patience to learn all of the magic incantations of the package
of the week.

Jon

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

* Re: [TUHS] V9 shell
  2020-02-12  0:12                         ` Jon Steinhart
@ 2020-02-12  1:03                           ` Warren Toomey
  2020-02-12  5:54                           ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Rob Pike
  1 sibling, 0 replies; 61+ messages in thread
From: Warren Toomey @ 2020-02-12  1:03 UTC (permalink / raw)
  To: tuhs

On Tue, Feb 11, 2020 at 04:12:51PM -0800, Jon Steinhart wrote:
> > Of course you are right, you will likely need to focus your mind,
> > and that requires an intellectual context, knowledge, to base upon.
> 
> Interesting that you mention this as I'm about to leave for a multi-day
> advanced yoga workshop.

And at this point I'd recommend that we move some of this out to COFF
as it's not Unix related.

Don't forget that the mailing list archive is itself a living archive of
Unix past and present: https://minnie.tuhs.org/pipermail/tuhs/

It now spans 25 years of postings. I really want it to have a high signal
to noise level so that future archive readers can find good information.

That's why COFF exists, so you can shoot the breeze and go off on tangents.
I've noticed some of you are self regulating & moving over to COFFS. Excellent!

Cheers, Warren

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-12  0:12                         ` Jon Steinhart
  2020-02-12  1:03                           ` [TUHS] V9 shell Warren Toomey
@ 2020-02-12  5:54                           ` Rob Pike
  1 sibling, 0 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-12  5:54 UTC (permalink / raw)
  To: Jon Steinhart, The Eunuchs Hysterical Society

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

Actually, I just took off a dull sweatshirt to reveal a bright shirt.

-rob

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 18:22                     ` Kurt H Maier
@ 2020-02-16 21:34                       ` Wesley Parish
  0 siblings, 0 replies; 61+ messages in thread
From: Wesley Parish @ 2020-02-16 21:34 UTC (permalink / raw)
  To: tuhs

It's the stuff of SF - hopefully a lot better than the glorified
"one-man shooter action" DooM fictionalizations we've seen (or not) so
many of ... COFF's Harbour ...

Wesley Parish

On 2/12/20, Kurt H Maier <khm@sciops.net> wrote:
> On Tue, Feb 11, 2020 at 06:05:01PM +0100, Steffen Nurpmeso wrote:
>>
>> I cannot imagine any other real step forward but control-by-
>> thought, aka brain computer interfaces.
>
> I can't even trust computers to do the right thing with input specially
> crafted for the program I'm using.  There is no way in hell I'm turning
> it loose on a direct neural interface.  Software engineering, as a
> discipline, is going to require a lot more actual discipline before
> neural interfaces become anything but fuel for a dystopian hellscape.
>
> I'm not saying we can't get there.  I'm saying we're not headed in that
> direction so far.
>
> khm
>

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11  3:32 Doug McIlroy
                   ` (4 preceding siblings ...)
  2020-02-11 14:36 ` Clem Cole
@ 2020-02-11 17:21 ` Dan Cross
  5 siblings, 0 replies; 61+ messages in thread
From: Dan Cross @ 2020-02-11 17:21 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

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

On Mon, Feb 10, 2020 at 10:34 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> Postel's principle: "be conservative in what you do, be liberal
> in what you accept from others" was doctrine in early HTML
> specs, and led to disastrous disagreement among browsers'
> interpretation of web pages. Sadly, the "principle" lives on
> despite its having been expunged from the HTML spec.
>

I think this is a bit unfair.

Postel was working in an environment where he was fighting an uphill battle
to get the Internet going and, perhaps more importantly, taken seriously: I
still vividly remember the derision that was heaped on it as a "research
toy" and how the "real" implementation was going to sweep it away, usually
in the form of ISO/OSI. An argument can be made that the Internet's
installed base and the fact that it largely worked despite imperfect
implementations headed off that particular trainwreck. Indeed, one wonders
if it would have even been viable as a research project had the early
ARPAnet and Internet implementors taken a hard stance on correctness.

That said, the HTML thing has always felt like a debacle to me, right from
the beginning.  It was an anaemic language delivered over a ridiculously
bad protocol (HTTP 0.9 or whatever).I fully confess that I completely
missed the World Wide Web thing when it first arrived on the scene.  To my
TeX and troff trained eyes used to interactive protocols, I couldn't see
the point. Boy was I wrong!

        - Dan C.

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 16:03   ` Bakul Shah
  2020-02-11 17:12     ` Clem Cole
@ 2020-02-11 17:17     ` Steve Nickolas
  1 sibling, 0 replies; 61+ messages in thread
From: Steve Nickolas @ 2020-02-11 17:17 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

On Tue, 11 Feb 2020, Bakul Shah wrote:

> I call it automiscorrect. First, it is very easy to mistype on these 
> touch based interfaces and then they miscorrect using too large a 
> vocabulary.

"AutocoWRECKED"

-uso.

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 16:03   ` Bakul Shah
@ 2020-02-11 17:12     ` Clem Cole
  2020-02-11 17:17     ` Steve Nickolas
  1 sibling, 0 replies; 61+ messages in thread
From: Clem Cole @ 2020-02-11 17:12 UTC (permalink / raw)
  To: Bakul Shah; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

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

On Tue, Feb 11, 2020 at 11:03 AM Bakul Shah <bakul@bitblocks.com> wrote:

> I call it automiscorrect.
>
I've been known to same something similar.  Usually with a #$%^& before it.


> First, it is very easy to mistype on these touch based interfaces and then
> they miscorrect using too large a vocabulary.
>
+1, amen brother Shah, amen,

>
> At USC, back when I was a student, they started us off with PL/C, a subset
> of PL/I. The PL/C compiler tried its level best to make sense of the
> student programs it was given, with error messages such as “PL/C uses
> ....”. This was confusing to many students as they would do exactly what
> PL/C said it used and yet their program didn’t work.
>
FWIW: I referenced both PL/C and IBM PL/1 compiler in my quora answer.
In an interactive world, offering a note like Grammerly's underline, seems
reasonable to me - because it forces me to accept it.   The automatic doing
it for me, is what I dislike - as you said, on touch interfaces it's
twice as bad.

I remember having a conversation with Doug Cooper when we all were teaching
the intro to CS course and I we were getting students turning in
'auto-corrected' code for assignments and wondering why the TAs were not
amused.  I had thought that having the compiler tell you what was in error
and then maybe offering a suggestion, might make sense, but there needed to
be some action on the student's part to accept >>and<< repair to code
before the compiler would produce something that 'ran.'

Anyway, I still think "*Damn Warren's Infernal Machine*" was always well
named.

Clem

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 14:36 ` Clem Cole
  2020-02-11 15:29   ` Mike Markowski
@ 2020-02-11 16:03   ` Bakul Shah
  2020-02-11 17:12     ` Clem Cole
  2020-02-11 17:17     ` Steve Nickolas
  1 sibling, 2 replies; 61+ messages in thread
From: Bakul Shah @ 2020-02-11 16:03 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

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

I call it automiscorrect. First, it is very easy to mistype on these touch based interfaces and then they miscorrect using too large a vocabulary.

At USC, back when I was a student, they started us off with PL/C, a subset of PL/I. The PL/C compiler tried its level best to make sense of the student programs it was given, with error messages such as “PL/C uses ....”. This was confusing to many students as they would do exactly what PL/C said it used and yet their program didn’t work.

> On Feb 11, 2020, at 6:38 AM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> Amen.  As a dyslexic (which most often shows when I'm typing as you folks have experienced) autocorrect generally is a PITA.   FWIW: Grammerly works well for me.  It underlines in dotted red and lets me look at what it thinks it should be - where I can accept it or not.   
> 
> Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried it also and let's just say it failed as I explain in a comment /answer on quora (https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead). 
> 
> Clem
> 
> 
> 
>> On Mon, Feb 10, 2020 at 10:33 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>> > What i like is the autocorrect feature in v8:
>> >
>> > $ cd /usr/blot
>> > /usr/blit
>> > $ pwd
>> > /usr/blit
>> 
>> Here I am, editor of the v8 manual and unaware of the feature.
>> We now know that silent correction is a terrible idea.
>> 
>> Postel's principle: "be conservative in what you do, be liberal
>> in what you accept from others" was doctrine in early HTML
>> specs, and led to disastrous disagreement among browsers'
>> interpretation of web pages. Sadly, the "principle" lives on 
>> despite its having been expunged from the HTML spec.
>> 
>> Today's "langsec" movement grew out of bitter experience
>> with malicious inputs exploiting "liberal" interpretation of
>> nonconforming data.
>> 
>> Today's NYT has an article about fake knockoffs of George Orwell
>> for sale on Amazon.  It cites an edition of "Animal Farm"
>> apparently pirated by lowgrade OCR autocorrected and never
>> proofread. One of the many gaffes is that every instance of
>> "iv" beame ChapterIV, as in "prChapterIVacy".
>> 
>> I didn't like some Lisp systems' DWIM (do what I mean) when I
>> first heard about the feature, and I like it even less 40-some
>> years on. I would probably have remonstrated with Rob had I
>> realized the shell was doing it.
>> 
>> Doug

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 11:24   ` Ralph Corderoy
@ 2020-02-11 15:51     ` Larry McVoy
  0 siblings, 0 replies; 61+ messages in thread
From: Larry McVoy @ 2020-02-11 15:51 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: tuhs, Doug McIlroy

On Tue, Feb 11, 2020 at 11:24:25AM +0000, Ralph Corderoy wrote:
> > > Postel's principle: "be conservative in what you do, be liberal in
> > > what you accept from others" was doctrine in early HTML specs, and
> > > led to disastrous disagreement among browsers' interpretation of web
> > > pages. Sadly, the "principle" lives on despite its having been
> > > expunged from the HTML spec.
> 
> I often point to this Internet Draft when Postel's Law is brought up in
> modern discussions about letting standards slip.
> 
>     The Harmful Consequences of Postel's Maxim
>     M. Thomson, Mozilla, 2015-03-09
>     https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
> 
> After looking at divergence over time, and long-term costs, it suggests
> instead ???Protocol designs and implementations should be maximally
> strict???.  A shame it never became an RFC.
> 
> Arguing Postel's Law for accepting to deviate is easy as those arguing
> for strictness have to work out how the laxness could cause a problem.

Perhaps I'm being too kind, but I think people are being a little hard
on Jon.  I believe what he was pushing for was "it just works".  Anyone
who has been involved with a long lived software base knows that as you
roll out new versions you can break backwards compat.  Nobody likes it 
when you do that.

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11 14:36 ` Clem Cole
@ 2020-02-11 15:29   ` Mike Markowski
  2020-02-11 16:03   ` Bakul Shah
  1 sibling, 0 replies; 61+ messages in thread
From: Mike Markowski @ 2020-02-11 15:29 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

My favorite example is a business trip my wife took.  Her surname is Hsi
which was "corrected" to His at the site she visited.  Upon arrival it took
her several *hours* to work out with the security folks that Ms Hsi was not
impersonating Ms His.  (That says as much about the security group as it
does about autocorrect, I suppose.)

Mike Markowski

On Tue, Feb 11, 2020 at 9:38 AM Clem Cole <clemc@ccc.com> wrote:

> Amen.  As a dyslexic (which most often shows when I'm typing as you folks
> have experienced) autocorrect generally is a PITA.   FWIW: Grammerly
> works well for me.  It underlines in dotted red and lets me look at what it
> thinks it should be - where I can accept it or not.
>
> Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried
> it also and let's just say it failed as I explain in a comment /answer on
> quora (
> https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead
> ).
>
> Clem
>
>

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11  9:40 ` arnold
@ 2020-02-11 15:06   ` Chet Ramey
  0 siblings, 0 replies; 61+ messages in thread
From: Chet Ramey @ 2020-02-11 15:06 UTC (permalink / raw)
  To: arnold, tuhs, doug

On 2/11/20 4:40 AM, arnold@skeeve.com wrote:
> Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> 
>>> What i like is the autocorrect feature in v8:
>>>
>>> $ cd /usr/blot
>>> /usr/blit
>>> $ pwd
>>> /usr/blit
>>
>> Here I am, editor of the v8 manual and unaware of the feature.
>> We now know that silent correction is a terrible idea.
> 
> But this isn't *silent* correction.  The shell tells you where
> it's putting you when it does this, same as in a 'cd' that
> happens via $CDPATH.
> 
> Admittedly, you have to be paying attention, but Unix has always
> demanded that of its users.

The one change I might consider is to disable this feature if the shell
is executing a command list, so something like

	cd /usr/bon && rm -f sh*

doesn't do something unexpected before a user has a chance to react.
Does the v9 shell do that?

Chet


-- 
``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] 61+ messages in thread

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11  3:32 Doug McIlroy
                   ` (3 preceding siblings ...)
  2020-02-11  9:40 ` arnold
@ 2020-02-11 14:36 ` Clem Cole
  2020-02-11 15:29   ` Mike Markowski
  2020-02-11 16:03   ` Bakul Shah
  2020-02-11 17:21 ` Dan Cross
  5 siblings, 2 replies; 61+ messages in thread
From: Clem Cole @ 2020-02-11 14:36 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

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

Amen.  As a dyslexic (which most often shows when I'm typing as you folks
have experienced) autocorrect generally is a PITA.   FWIW: Grammerly works
well for me.  It underlines in dotted red and lets me look at what it
thinks it should be - where I can accept it or not.

Doug -- I agree DWIM was just silly.... UCB's Pascal system (pix) tried it also
and let's just say it failed as I explain in a comment /answer on quora (
https://www.quora.com/When-you-are-programming-and-commit-a-minor-error-such-as-forgetting-a-semicolon-the-compiler-throws-an-error-and-makes-you-fix-it-for-yourself-Why-doesn-t-it-just-fix-it-by-itself-and-notify-you-of-the-fix-instead
).

Clem



On Mon, Feb 10, 2020 at 10:33 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > What i like is the autocorrect feature in v8:
> >
> > $ cd /usr/blot
> > /usr/blit
> > $ pwd
> > /usr/blit
>
> Here I am, editor of the v8 manual and unaware of the feature.
> We now know that silent correction is a terrible idea.
>
> Postel's principle: "be conservative in what you do, be liberal
> in what you accept from others" was doctrine in early HTML
> specs, and led to disastrous disagreement among browsers'
> interpretation of web pages. Sadly, the "principle" lives on
> despite its having been expunged from the HTML spec.
>
> Today's "langsec" movement grew out of bitter experience
> with malicious inputs exploiting "liberal" interpretation of
> nonconforming data.
>
> Today's NYT has an article about fake knockoffs of George Orwell
> for sale on Amazon.  It cites an edition of "Animal Farm"
> apparently pirated by lowgrade OCR autocorrected and never
> proofread. One of the many gaffes is that every instance of
> "iv" beame ChapterIV, as in "prChapterIVacy".
>
> I didn't like some Lisp systems' DWIM (do what I mean) when I
> first heard about the feature, and I like it even less 40-some
> years on. I would probably have remonstrated with Rob had I
> realized the shell was doing it.
>
> Doug
>

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

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11  3:53 ` Larry McVoy
@ 2020-02-11 11:24   ` Ralph Corderoy
  2020-02-11 15:51     ` Larry McVoy
  0 siblings, 1 reply; 61+ messages in thread
From: Ralph Corderoy @ 2020-02-11 11:24 UTC (permalink / raw)
  To: tuhs; +Cc: Doug McIlroy

Hi Larry,

> Doug McIlroy wrote:
> > We now know that silent correction is a terrible idea.
>
> I had the same thought,
>
>     cd /some/place/I/want/to/remove
>     $PWD is /some/place/I/want/dont/remove
>     rm -rf ./*

An extract from the Jargon File's DWIM entry echoes that.

    http://www.catb.org/~esr/jargon/html/D/DWIM.html

    In one notorious incident, Warren added a DWIM feature to the
    command interpreter used at Xerox PARC.  One day another hacker
    there typed delete *$ to free up some disk space.  (The editor there
    named backup files by appending $ to the original file name, so he
    was trying to delete any backup files left over from old editing
    sessions.)  It happened that there weren't any editor backup files,
    so DWIM helpfully reported *$ not found, assuming you meant 'delete
    *'.  It then started to delete all the files on the disk!  The
    hacker managed to stop it with a Vulcan nerve pinch after only a
    half dozen or so files were lost.

    The disgruntled victim later said he had been sorely tempted to go
    to Warren's office, tie Warren down in his chair in front of his
    workstation, and then type delete *$ twice.

> > Postel's principle: "be conservative in what you do, be liberal in
> > what you accept from others" was doctrine in early HTML specs, and
> > led to disastrous disagreement among browsers' interpretation of web
> > pages. Sadly, the "principle" lives on despite its having been
> > expunged from the HTML spec.

I often point to this Internet Draft when Postel's Law is brought up in
modern discussions about letting standards slip.

    The Harmful Consequences of Postel's Maxim
    M. Thomson, Mozilla, 2015-03-09
    https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00

After looking at divergence over time, and long-term costs, it suggests
instead ‘Protocol designs and implementations should be maximally
strict’.  A shame it never became an RFC.

Arguing Postel's Law for accepting to deviate is easy as those arguing
for strictness have to work out how the laxness could cause a problem.

(I'm sad to see Golang accepting deviations from standards.  It has been
a big enough language to take a stand for ages.
https://github.com/golang/go/issues/34540 is one example of a CVE from
allowing white-space where there shouldn't be any in the HTTP protocol.
Just white-space, what could be harmful about accepting that?
https://github.com/golang/go/issues/19989 was another HTTP white-space
deviation from the spec.  All to help one particular unnamed GPS system.)

-- 
Cheers, Ralph.

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  3:32 Doug McIlroy
                   ` (2 preceding siblings ...)
  2020-02-11  6:33 ` Rob Pike
@ 2020-02-11  9:40 ` arnold
  2020-02-11 15:06   ` Chet Ramey
  2020-02-11 14:36 ` Clem Cole
  2020-02-11 17:21 ` Dan Cross
  5 siblings, 1 reply; 61+ messages in thread
From: arnold @ 2020-02-11  9:40 UTC (permalink / raw)
  To: tuhs, doug

Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > What i like is the autocorrect feature in v8:
> >
> > $ cd /usr/blot
> > /usr/blit
> > $ pwd
> > /usr/blit
>
> Here I am, editor of the v8 manual and unaware of the feature.
> We now know that silent correction is a terrible idea.

But this isn't *silent* correction.  The shell tells you where
it's putting you when it does this, same as in a 'cd' that
happens via $CDPATH.

Admittedly, you have to be paying attention, but Unix has always
demanded that of its users.

Note that I am not arguing with the idea that silent correction
is bad; I'm merely pointing out that this is not an instance of that.

Thanks,

Arnold

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

* Re: [TUHS] V9 shell [was Re: Warner's Early Unix Presentation]
  2020-02-11  3:32 Doug McIlroy
  2020-02-11  3:53 ` Larry McVoy
  2020-02-11  4:46 ` Warren Toomey
@ 2020-02-11  6:33 ` Rob Pike
  2020-02-11  9:40 ` arnold
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 61+ messages in thread
From: Rob Pike @ 2020-02-11  6:33 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

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

On Tue, Feb 11, 2020 at 2:34 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> > What i like is the autocorrect feature in v8:
> >
> > $ cd /usr/blot
> > /usr/blit
> > $ pwd
> > /usr/blit
>
> I didn't like some Lisp systems' DWIM (do what I mean) when I
> first heard about the feature, and I like it even less 40-some
> years on. I would probably have remonstrated with Rob had I
> realized the shell was doing it.
>

It was td, and there is an implementation of sorts in The Unix Programming
Environment.

-rob

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

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  4:46 ` Warren Toomey
@ 2020-02-11  5:12   ` Steve Nickolas
  0 siblings, 0 replies; 61+ messages in thread
From: Steve Nickolas @ 2020-02-11  5:12 UTC (permalink / raw)
  To: Warren Toomey; +Cc: tuhs, Doug McIlroy

On Tue, 11 Feb 2020, Warren Toomey wrote:

> On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote:
>> years on. I would probably have remonstrated with Rob had I
>> realized the shell was doing it.
>> Doug
>
> I misread that as "what the shell was going on", which seems appropriate.
>
> 	Warren
>

Too much Ninja Turtles '03?

-uso.

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  3:32 Doug McIlroy
  2020-02-11  3:53 ` Larry McVoy
@ 2020-02-11  4:46 ` Warren Toomey
  2020-02-11  5:12   ` Steve Nickolas
  2020-02-11  6:33 ` Rob Pike
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 61+ messages in thread
From: Warren Toomey @ 2020-02-11  4:46 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: tuhs

On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote:
> years on. I would probably have remonstrated with Rob had I
> realized the shell was doing it.
> Doug

I misread that as "what the shell was going on", which seems appropriate.

	Warren

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
  2020-02-11  3:32 Doug McIlroy
@ 2020-02-11  3:53 ` Larry McVoy
  2020-02-11 11:24   ` Ralph Corderoy
  2020-02-11  4:46 ` Warren Toomey
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 61+ messages in thread
From: Larry McVoy @ 2020-02-11  3:53 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: tuhs

On Mon, Feb 10, 2020 at 10:32:58PM -0500, Doug McIlroy wrote:
> > What i like is the autocorrect feature in v8:
> >
> > $ cd /usr/blot
> > /usr/blit
> > $ pwd
> > /usr/blit
> 
> Here I am, editor of the v8 manual and unaware of the feature.
> We now know that silent correction is a terrible idea.

I had the same thought,

cd /some/place/I/want/to/remove
$PWD is /some/place/I/want/dont/remove
rm -rf ./*

oops.

> Postel's principle: "be conservative in what you do, be liberal
> in what you accept from others" was doctrine in early HTML
> specs, and led to disastrous disagreement among browsers'
> interpretation of web pages. Sadly, the "principle" lives on 
> despite its having been expunged from the HTML spec.

I think Jon had the right intentions.  HTML is different than
a command prompt.

> I didn't like some Lisp systems' DWIM (do what I mean) when I
> first heard about the feature, and I like it even less 40-some
> years on. I would probably have remonstrated with Rob had I
> realized the shell was doing it.

Yep, agreed.   There are places where that works and there are most
definitely places where they do not.  The shell should not guess.

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

* Re: [TUHS] V9 shell [was Re:  Warner's Early Unix Presentation]
@ 2020-02-11  3:32 Doug McIlroy
  2020-02-11  3:53 ` Larry McVoy
                   ` (5 more replies)
  0 siblings, 6 replies; 61+ messages in thread
From: Doug McIlroy @ 2020-02-11  3:32 UTC (permalink / raw)
  To: tuhs

> What i like is the autocorrect feature in v8:
>
> $ cd /usr/blot
> /usr/blit
> $ pwd
> /usr/blit

Here I am, editor of the v8 manual and unaware of the feature.
We now know that silent correction is a terrible idea.

Postel's principle: "be conservative in what you do, be liberal
in what you accept from others" was doctrine in early HTML
specs, and led to disastrous disagreement among browsers'
interpretation of web pages. Sadly, the "principle" lives on 
despite its having been expunged from the HTML spec.

Today's "langsec" movement grew out of bitter experience
with malicious inputs exploiting "liberal" interpretation of
nonconforming data.

Today's NYT has an article about fake knockoffs of George Orwell
for sale on Amazon.  It cites an edition of "Animal Farm"
apparently pirated by lowgrade OCR autocorrected and never
proofread. One of the many gaffes is that every instance of
"iv" beame ChapterIV, as in "prChapterIVacy".

I didn't like some Lisp systems' DWIM (do what I mean) when I
first heard about the feature, and I like it even less 40-some
years on. I would probably have remonstrated with Rob had I
realized the shell was doing it.

Doug

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

end of thread, back to index

Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-07 22:25 [TUHS] Warner's Early Unix Presentation Warren Toomey
2020-02-07 23:57 ` Rob Pike
2020-02-08  0:43   ` Warren Toomey
2020-02-08  3:37     ` Warner Losh
2020-02-08 15:15   ` Warner Losh
2020-02-08 21:50     ` Rob Pike
2020-02-08 22:29       ` Chet Ramey
2020-02-08 22:54         ` Rob Pike
2020-02-08 23:02           ` Chet Ramey
2020-02-08 23:11             ` Rob Pike
2020-02-08 23:13               ` Rob Pike
2020-02-08 23:21               ` Kurt H Maier
2020-02-08 23:26                 ` Rob Pike
2020-02-08 23:28                   ` Chet Ramey
2020-02-08 23:26               ` Chet Ramey
2020-02-08 23:29                 ` Rob Pike
2020-02-08 23:35                   ` Warner Losh
2020-02-08 23:36                   ` Chet Ramey
2020-02-08 23:54                     ` Rob Pike
2020-02-09  0:11                       ` Chet Ramey
2020-02-09  0:19                   ` Larry McVoy
2020-02-08 22:31       ` Richard Salz
2020-02-10 13:18       ` Tony Finch
2020-02-10 15:05       ` Dan Cross
2020-02-10 15:46         ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] arnold
2020-02-10 18:39           ` Rob Pike
2020-02-10 18:59             ` Bakul Shah
2020-02-10 19:58             ` Angelo Papenhoff
2020-02-10 20:11               ` Chet Ramey
2020-02-11  9:33             ` arnold
2020-02-11  9:47               ` Noel Hunt
2020-02-11  9:47               ` Rob Pike
2020-02-11  9:59                 ` Rob Pike
2020-02-11 17:05                   ` Steffen Nurpmeso
2020-02-11 17:18                     ` Arthur Krewat
2020-02-11 18:22                     ` Kurt H Maier
2020-02-16 21:34                       ` Wesley Parish
2020-02-11 18:26                     ` Jon Steinhart
2020-02-11 23:56                       ` Steffen Nurpmeso
2020-02-12  0:12                         ` Jon Steinhart
2020-02-12  1:03                           ` [TUHS] V9 shell Warren Toomey
2020-02-12  5:54                           ` [TUHS] V9 shell [was Re: Warner's Early Unix Presentation] Rob Pike
2020-02-11 17:36                   ` Dan Cross
2020-02-11 18:35                   ` Christopher Browne
2020-02-11 18:54                     ` Rob Pike
2020-02-11 21:36                     ` Harald Arnesen
2020-02-11  3:32 Doug McIlroy
2020-02-11  3:53 ` Larry McVoy
2020-02-11 11:24   ` Ralph Corderoy
2020-02-11 15:51     ` Larry McVoy
2020-02-11  4:46 ` Warren Toomey
2020-02-11  5:12   ` Steve Nickolas
2020-02-11  6:33 ` Rob Pike
2020-02-11  9:40 ` arnold
2020-02-11 15:06   ` Chet Ramey
2020-02-11 14:36 ` Clem Cole
2020-02-11 15:29   ` Mike Markowski
2020-02-11 16:03   ` Bakul Shah
2020-02-11 17:12     ` Clem Cole
2020-02-11 17:17     ` Steve Nickolas
2020-02-11 17:21 ` Dan Cross

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git