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 <k...@munnari.oz.au> wrote: > Date: Tue, 16 Mar 2021 13:26:30 +0100 > From: Alex fxmbsw7 Ratchev <fxmb...@gmail.com> > Message-ID: <CAALKErHuHduuMLBnhXzxuoEVqT-cjJeeVBV8f7WQO= > p09ca...@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. > > g...@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 > > >
