On Sat, Feb 08, 2020 at 10:57:41AM +1100, Rob Pike wrote: 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

On Fri, Feb 7, 2020 at 4:58 PM Rob Pike <robpike(a)gmail.com> wrote: 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. 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. 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 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

On 2/8/20 4:50 PM, Rob Pike wrote: 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(a)case.edu http://tiswww.cwru.edu/~chet/

On 2/8/20 5:54 PM, Rob Pike wrote: 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(a)case.edu http://tiswww.cwru.edu/~chet/

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(a)gmail.com> wrote:

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(a)sciops.net> wrote:

On 2/8/20 6:11 PM, Rob Pike wrote: 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. 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? 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(a)case.edu http://tiswww.cwru.edu/~chet/

On Sat, Feb 8, 2020, 4:29 PM Rob Pike <robpike(a)gmail.com> wrote: 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

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(a)case.edu> wrote:

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" }

Rob Pike <robpike(a)gmail.com> wrote: 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(a)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.

Dan Cross <crossd(a)gmail.com> wrote: 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

On Tue, 11 Feb 2020 05:39:26 +1100 Rob Pike <robpike(a)gmail.com> wrote: ^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.

On 2/10/20 2:58 PM, Angelo Papenhoff wrote: 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(a)case.edu http://tiswww.cwru.edu/~chet/

2020年2月11日(火) 18:34 <arnold(a)skeeve.com>: Muxterm, the default user-interface window under mux, was most definitely editable.

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

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:

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(a)sciops.net> wrote:

Jon Steinhart wrote in <202002111826.01BIQp2A1764361(a)darkstar.fourwinds.com>: |Steffen Nurpmeso writes: |> Rob Pike wrote in |> <CAKzdPgz6qPuqOfTe4eLqmM4f4RXTxqWRO-3NLHTaMxJg7mT-Nw(a)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)

On Tue, Feb 11, 2020 at 04:12:51PM -0800, Jon Steinhart wrote: 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

On Tue, Feb 11, 2020 at 4:59 AM Rob Pike <robpike(a)gmail.com> wrote: 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, 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.

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(a)gmail.com> wrote: