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

[Paxsali]

declare -p arr;

not declare -n

(Auto complete on the phone does whatever it wants, apparently)

Paxsali <akis.kapo@googlemail.com> schrieb am Mo., 29. Jan. 2024, 16:31:

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