This is essentially equivalent to urls=("$urls2"). Even though it behaves like a plain variable, it is probably not ideal in the long run.

Nevertheless, it is still a good workaround.

Pinging @wolfgangwalther @MattSturgeon for input.

Since spaces are invalid in URLs, this should be OK in practice, right?

When I initially looked, my reaction was “let's just use arrays correctly and consistently.” But yes, spaces being invalid makes it mostly a non-issue in practice.

One potential subtlety is what error you get when you pass an invalid URL with a space... If we handle arrays correctly, then the error will come from passing curl an invalid URL. With the current implementation, the error will instead show up as passing curl multiple URL fragments.

While I'd like to see this implementation cleaned up, for me it doesn't block this PR.

My main concern is how would users access urls in postFetch. This fix allows accessing it as "$urls", which is compatible with pre-structured-attrs behavior, but

• People and tools would expect urls be passed as a Bash array when [[ -n "${__structuredAttes-}" ]].
• declare -p urls will show it's a Bash array, but it cnnot be accessed as such.
• If users try to access urls in netrcPhase, they need to Access it as a Bash array.

While I'd like to see this implementation cleaned up, for me it doesn't block this PR.

I agree. Let's merge it first.

I was wrong about the "behave like a plain variable" part.

This fix is bugged -- it doesn't work the way we have thought.

$ foo=(a b)
$ declare -p foo
declare -a foo=([0]="a" [1]="b")
$ foo="${foo[*]}"
$ declare -p foo
declare -a foo=([0]="a b" [1]="b")
$ declare foo="${foo[*]}"
$ declare -p foo
declare -a foo=([0]="a b b" [1]="b")

You are showing how foo="${foo[*]}" doesn't work as expected. But we don't do urls="${urls2[*]}", we do urls="$urls2". So I don't see the connection, yet.

But we don't do urls=\"${urls2[*]}\", we do urls=\"$urls2\".

The problemis the same. It is essentially urls[0]=$urls2. We thought we were rewrititng urls, but it is just urls[0].

Ah, I found the mistake in my test-case. It's not exactly the same behavior as above, but yes only the first element is replaced with the other first element.

When I initially looked, my reaction was “let's just use arrays correctly and consistently.” But yes, spaces being invalid makes it mostly a non-issue in practice.

One potential subtlety is what error you get when you pass an invalid URL with a space... If we handle arrays correctly, then the error will come from passing curl an invalid URL. With the current implementation, the error will instead show up as passing curl multiple URL fragments.

While I'd like to see this implementation cleaned up, for me it doesn't block this PR.