On Sun, 15 Oct 2023, 02:03 Robert Elz, <k...@munnari.oz.au> wrote: > Date: Sat, 14 Oct 2023 14:46:12 +1000 > From: Martin D Kealey <mar...@kurahaupo.gen.nz> > Message-ID: <CAN_U6MX60UN+wfNpHU1pzQRzCaHgt_c+N= > a2+3nnknhm5a+...@mail.gmail.com> > > > | Back when I used the Bourne Shell we didn't have `local`, so we used to > | write `var= func` to make sure that `func` couldn't mess with *our* > `var`. > > If you were using the original Bourne shell you couldn't have done that, > as it had no functions either.
Fair point, it was just whatever was /bin/sh on Ultrix at the time. I was a uni student so I don't even know what version of Ultrix we were using. I take your point that the Shell (and especially Bash) has grown Frankenfeatures way beyond a mere command interpreter, in ways that are fundamentally irreconcilable. But I don't think sticking to our guns about "let's go back to simple" is the best way forward. The one thing to be said for the Shell is that it's universal. If we kill it, what will take its place? I already have to install Bash, Awk, Perl, Python, and Node just to have a running system. How many more will be needed after Bash finally dies? If the Shell is left out in no man's land, with a shortfall in features so it can't be a "real" programming language, but at the same time with the crazy complexity for users to learn, we pretty much doom it to extinction. If the Shell is truly a moribund legacy language, we should stop changing it. No new features. No "bug fixes". No new safety guards. Or we design a new language that feels more like a regular programming language even if its syntax is weird. In my opinion it should have: Proper per-package feature selection; proper lexically scoped variables & functions; opt-in rather than opt-out globbing & word splitting; opt-in rather than opt-out filedescriptor inheritance; strongly typed variables, with string/number/array/compound/filehandle values; distinguishable binary (octet-stream) and text (Unicode/utf-8), with support for null bytes in strings, and a Cstring attribute to prohibit assignments that include null bytes (because execve is so central to everything); support for AF_LOCAL sockets as bidirectional pipes; exceptions separate from exit-status, with ability to enrol some but not all commands for the set-e treatment. Yes that's far too much work for one person; I do not expect Chet to do all this, I expect there to be a governance team.
