Re: uninvited members of associative array

[Dominik Vogt <dominik.vogt@xxxxxx>]

On Fri, Dec 16, 2022 at 12:10:22PM -0800, Ray Andrews wrote:
> > I think you have a grave misconception of shells. Shells are
> > basically command line interpreters with some text processing.
> I know it.  All the extra functionality accreted over the years. It's an
> evolutionary cul-de-sac in that the latter additions are somewhat clumsy in
> as much as they have to contend with the earlier design.  Can't be helped.

> > There's no
> > conception of symbolic values; all input is just text.
> Except for those times when I wish it is was 'just text' but instead things
> are expanded.  Anyway how is a variable name not a symbol for the contents
> of the variable?

But variables are not even a real part of the shell, the shell
script or its data.  Every process has an associated environment
that consists of "key=value" pairs.  The parameter syntax in the
shell is just a way to manipulate the environment that is then
passed to the started processes.  The environment exists
independently of the shell.

> > Shells are
> > are not "programming languages".
> That's a strange thing to hear.  A program is a list of things on asks a
> computer to accomplish and zsh accomplishes them.  But you know more about
> all this than I do.

To begin with, the shell does not even have a fixed syntax that
could be written down in a rule book:  You can change the meaning
of the "program" from inside the program, for example by changing
options at run time or by overwriting the IFS variable, e.g.

  $ A="a,b-c"
  $ echo "$A"
  a,b-c

  # fiddle with IFS
  $ IFS=","
  echo "$A"
  a b-c

  # or even read value from user input
  $ read IFS
  -<return>
  $ echo "$A"
  a,b c

  # fiddling with options
  $ X=(a b c d e)
  $ setopt ksh_arrays; echo "${#X}"
  2
  $ unsetopt ksh_arrays; echo "${#X}"
  5

  # user input defines type of parameter
  $ unset A
  $ A[foo]=bar
  zsh: A: assignment to invalid subscript range
  $ read X
  -A<return>
  $ typeset "$X" A
  $ A[foo]="bar"
  $ echo "$(kv)A}"
  foo bar

  # redefine commands, aliases or even builtins
  $ read X
  ls<return>
  $ alias echo="$X"
  $ echo "Hello, world!"
  ls: cannot access 'Hello, world!': No such file or directory

I.e. the semantics of the script may depend on user input.

Then, the commands that the shell runs are mostly not defined by
the shell but externally.  You'd probably describe the script

  ls .
  rm -f foobarbaz

as "a program that lists non-hidden entries of the current
directory and then removes the entry foobarbaz if it exists and is
not a directory".  But that is not true.  What the script really
does is "execute a program 'ls' with argument '.', then execute a
program 'rm' with arguments '-f' 'foobarbaz'".  What the called
programs do is not part of the shell.  So, unless you want to
define the program as a sequence of "execute X with arguments Y1
... Yn" the shell really doesn't do anything close to what the
"program" is supposed to do.

--

Of course modern shells have lots of self contained builtin
commands and control structures that resemble programming
languages.

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt