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

[Paxsali]

In response to what Alex Xmb said:

The following form...:

str='a * ! d';
mapfile -t -d ' ' arr < <(printf '%s' "${str}");
declare -n arr

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

...also does the trick without the unnecessary quoting/escaping, unless
that's really what you want.

You must use process substitution here, because using a pipe opens a
subshell and the variable is lost. Using here strings (<<<"${str}") is also
possible and equally short and elegant, however it introduces a trailing
newline that you cannot get rid of (unless you add more commands).

alex xmb sw ratchev <fxmbsw7@gmail.com> schrieb am Mo., 29. Jan. 2024,
13:41:

> 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".
> >
> >
>