Re: variable set in exec'ing shell cannot be unset by child shell

[Martin D Kealey]

On Sun, 15 Oct 2023, 02:03 Robert Elz, <kre@munnari.oz.au> wrote:

>     Date:        Sat, 14 Oct 2023 14:46:12 +1000
>     From:        Martin D Kealey <martin@kurahaupo.gen.nz>
>     Message-ID:  <CAN_U6MX60UN+wfNpHU1pzQRzCaHgt_c+N=
> A2+3NnkNHM5a+nTQ@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.