(And if you need to check the contents of an array -- or even a plain variable -- declare -p arr is more reliable than echo.)

If you have an older version of bash that doesn't support readarray (i.e. you're on macOS), you can fake it with read and some delimiter switching:

IFS=$'\n' read -d '' -a arr < <(jq -rn --argjson j "$raw_containers_string" '$j[].name') 

Here, the -d '' part makes it treat the entire thing as one big line, and IFS=$'\n' tells it to break that "line" into fields on newline delimiters. Since the IFS assignment is a prefix to the read command, it only applies to that one command and won't cause trouble later. One warning, though: technically, the read command will exit with an error status (because it never saw an end-of-line delimiter), so if you use set -e or shopt -s errexit it'll make the script exit (add || true at the end to prevent this).

(And if you need to check the contents of an array -- or even a plain variable -- declare -p arr is more reliable than echo.)

You're counting on word-splitting of unquoted variable/command substitutions to separate the elements of the array, and have apparently also changed IFS. These are both bad ideas, and together they're a recipe for chaos. You're also using zsh for interactive testing, and it does word splitting very differently from bash, so you'll get different weird results from it.

First, track down what's changing IFS and fix it. You appear to have it set to something really weird, containing at least "m", "n", "a", and "e", so it's probably set by mistake.

If it actually does need to be changed, you need to keep it from staying changed. You can either make the change local to a specific command by making it a prefix of the command (e.g. IFS=',' read field1 field2) or by resetting it after using the changed value (e.g. saveIFS="$IFS"; IFS=","; doSomethingWithIFS; IFS="$saveIFS"), or just find a different way to solve whatever you changed IFS` for in the first place.

Second, get in the habit of double-quoting variable and command substitutions. There are some specific situations where you shouldn't double-quote them, and some situations where it's optional, but it's safest to just assume it should be double-quoted in most cases. shellcheck.net is good at pointing out quoting problems (and many other common mistakes).

Instead of using word-splitting on an unquoted substitution to populate the array, use readarray -t to read each line of input into a separate array element (or read -ra to read words into elements -- but fix IFS first, or it'll also split weirdly). Note that you can't put these in a pipeline, or they execute in a subshell and the value gets lost; instead, use process substitution: readarray -t < <(somecommand)

Third, that grep | cut thing is going to output something with extra spaces and quotes around the actual values. Anyway, when parsing JSON, it's better to use a tool like jq that actually speaks the language.

So, with all that fixed, try this:

readarray -t arr < <(echo "$raw_containers_string" | jq -r '.[].name') 

(And if you need to check the contents of an array -- or even a plain variable -- declare -p arr is more reliable than echo.)

You're counting on word-splitting of unquoted variable/command substitutions to separate the elements of the array, and have apparently also changed IFS. These are both bad ideas, and together they're a recipe for chaos. You're also using zsh for interactive testing, and it does word splitting very differently from bash, so you'll get different weird results from it.

First, track down what's changing IFS and fix it. You appear to have it set to something really weird, containing at least "m", "n", "a", and "e", so it's probably set by mistake.

If it actually does need to be changed, you need to keep it from staying changed. You can either make the change local to a specific command by making it a prefix of the command (e.g. IFS=',' read field1 field2) or by resetting it after using the changed value (e.g. saveIFS="$IFS"; IFS=","; doSomethingWithIFS; IFS="$saveIFS"), or just find a different way to solve whatever you changed IFS` for in the first place.

Second, get in the habit of double-quoting variable and command substitutions. There are some specific situations where you shouldn't double-quote them, and some situations where it's optional, but it's safest to just assume it should be double-quoted in most cases. shellcheck.net is good at pointing out quoting problems (and many other common mistakes).

Instead of using word-splitting on an unquoted substitution to populate the array, use readarray -t to read each line of input into a separate array element (or read -ra to read words into elements -- but fix IFS first, or it'll also split weirdly). Note that you can't put these in a pipeline, or they execute in a subshell and the value gets lost; instead, use process substitution: readarray -t < <(somecommand)

Third, that grep | cut thing is going to output something with extra spaces and quotes around the actual values. Anyway, when parsing JSON, it's better to use a tool like jq that actually speaks the language.

So, with all that fixed, try this:

readarray -t arr < <(echo "$raw_containers_string" | jq -r '.[].name') 

Léa Gris pointed out that you can simplify this even further by passing the string to jq with --argjson instead of echo and a pipe:

readarray -t arr < <(jq -rn --argjson j "$raw_containers_string" '$j[].name') 

(And if you need to check the contents of an array -- or even a plain variable -- declare -p arr is more reliable than echo.)