Re: looping over variables & exporting them at the same time ?

[alex xmb sw ratchev]

On Mon, Jan 29, 2024, 13:29 Greg Wooledge <greg@wooledge.org> wrote:

> On Sun, Jan 28, 2024 at 11:43:49PM -0500, Zachary Santer wrote:
> > Why do
> > IFS=' ' read -ra list <<< "${!v}"
> > instead of
> > list=( ${!v} )
>
> The second form does word splitting using the default IFS, so you would
> want to change that.  This leaves IFS in an altered state (you can't
> temporarily assign it for this command only, because it's an assignment),
> unless the assignment is done inside a function where IFS is local.
>
> It also does globbing (filename expansion), which you would need to
> suppress.  Once again, this leaves the shell in an altered state, unless
> you use "local -" inside a function to localize the -f/+f setting.
> That in turn would bump up the required bash version to 4.4.
>

u got some more arguments to make a non read work ? just for experimenting
with knowledge / benchmarking

~ $ str=' a * ! d ' ; foo() ( set -f ; IFS=' ' ; printf %q\ $@ ) ; declare
-a arr=( $( foo "$str" ) ) ; declare -p arr

declare -a arr=([0]="a" [1]="\\*" [2]="\\!" [3]="d")

But, really?  The main reason you don't do x=( $y ) is because it's got
> an unquoted expansion just waiting to cause *untold* amounts of trouble.
> Even if you think you've covered all your bases, who knows what strange
> behaviors or shell bugs are just waiting to leap out and bite you.
>
> > And nameref variables could simplify what you're doing as well.
>
> That's fair, although it does bump up the required bash version to 4.3.
>
> > I'm curious if the guy's actual use-case is even really a list, or if
> > that's being extrapolated out of the example he made of what he wanted to
> > be able to do. If these things are lists, they should live and die as
> > arrays, but then you can't export them.
>
> It's impossible to be sure, of course.  I'm guessing this is part of
> some kind of autobuilder ("continuous integration") setup.  This guess
> is based on past questions I've seen, rather than the current question
> alone.  These "CI" thingamabobs tend to abuse environment variables to
> pass all kinds of crap around, and they use rickety shell scripts to
> try to control it all.
>
> I'm still concerned about the variable names being used.  I still have a
> deeply skeptical belief that there isn't a known, finite set of variable
> names to be iterated over.  I'm expecting the next iteration of the
> question to be "I lied, and the variables are all of the form XYZ_* and
> I have to change all of them, and I won't know in advance what they are".
>
> Or worse still, "I have to use /bin/sh, not bash".
>
>