Re: Changing the way bash expands associative array subscripts

[Alex fxmbsw7 Ratchev]

you write like when word splitting no use double quotes
sure but as far as i understood:
key='$( faulty_command )'
unset -v assoc["$key"]
would still get expanded

i cant get friendly'ed to builtins being over keywords

much more to say but i cant, greets tho

On Wed, Mar 17, 2021 at 4:46 AM Robert Elz <kre@munnari.oz.au> wrote:

>     Date:        Tue, 16 Mar 2021 13:26:30 +0100
>     From:        Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
>     Message-ID:  <CAALKErHuHduuMLBnhXzxuoEVqT-cjJeeVBV8f7WQO=
> p09Ca75w@mail.gmail.com>
>
>   | no idea about your internal rules of keyword and builtin but clearly
> its
>   | gotta parse it at most 1. level otherwise its big security fault isnt
> it
>
> No, it isn't.   No more than
>         cd /; rm -fr *
> is a "big security fault" (in the shell).   Users who do
> stupid things might be a big security fault, but it is not the
> shell's job to stop that (if you think you need that help,
> find some shell that still implements restricted mode, if there
> are any (does bash?) and use that, then you'll be fairly well
> protected - you also won't be able to do much).
>
>   | its a shell fuctionality keyword, unset, so ..
>
> Lots of things are what seems to be shell functionality, that
> changes nothing.   If you don't want word splitting, add quotes.
> Your responsibility.
>
> greg@wooledge.org said:
>   | I would not complain if unset became a shell keyword, and had a
> complete
>   | revamp of its behavior.
>
> I would.   keywords cannot be overridden by functions, and so should be
> used only where absolutely required (which means, really, that in order to
> work, they require a magic syntax, that the shell must implement).
> And yes '[[' being a keyword, is, IMO, a mistake.   unset requires
> no more than regular shell parsing, and should be left alone.
>
> kre
>
>
>