As part of a Travis build, I’m running a relatively simple bash script downloaded from here. The result of running the script on xenial and bionic are inconsistent and in both cases, I’m getting erroneous behavior that I can’t replicate with the same versions of bash running in a Docker container on my local machine. Further, everything works perfectly on MacOS builds with the same script (run with a recent version of bash installed from homebrew).
A recent build that demonstrates the behavior is here and the configuration is here. In the first job here running on bionic, I set the value of the variable COMMON_ARGS (a bash array) in the script here like so:
COMMON_ARGS=(--no-prompt --verbosity ${VERBOSITY:-2} --tests main --enable-relocatable)
Afterwards, I echo it’s value here (along with the values of some other variables) like so:
echo "${COMMON_ARGS[@]}" "${ADD_ARGS[@]}" "${DBG_ARGS[@]}"
but the variables whose values were just set are now empty.
You cannot export array variables. Because an envvar can only be a string and there’s no one true conversion method.
I could not reproduce the issue locally but I can say for sure that export ARRAY_VAR does not make ARRAY_VAR an envvar:
$ export COMMON_ARGS=(--no-prompt --verbosity ${VERBOSITY:-2} --tests main --enable-relocatable)
$ printenv | grep COMMON_ARGS
$
so whether it works or not, it’s pointless anyway.
After removing exports from setup_environment.sh, echo prints values as expected: https://travis-ci.com/github/native-api/Clp/jobs/387717751#L458-L463 .
I actually didn’t realize that you couldn’t export arrays, thanks for clarifying that. I actually tried removing all the exports at some point, but that caused other issues, since some of the variables really do need to be exported. Fortunately, the arrays don’t need to be, so I can forgo exporting those as a workaround and continue exporting others.
Nevertheless, this seems to be buggy behavior. Exporting shouldn’t actually prevent the variable from being set locally and it doesn’t do so on most of my builds. The fact that arrays can’t be exported is correct behavior of bash and nothing to do with Travis. The fact that exporting arrays blocks them from being set locally seems to be a Travis bug and is the thing that is relevant here. I will open a new post just focusing on that. It must have to do something with whatever wrapper Travis is using the run these scripts.
Anyway, this has been very helpful in zeroing in on what’s really going on. Thanks!
I marked your first answer as the solution, since the title is now about the += behavior, but the problem description references more than just this issue and I don’t have any way of cleaning that up. Sorry for mixing the two issues, but it wasn’t that clear to me at first that they weren’t related.
Of course. But with reasonable effort, I cannot see what the bug is triggered by. E.g. if I echo a var in the same script, it doesn’t show, but if I echo it in a separate .travis.yml command entry later, it prints correctly. So this looks like an issue local to a Bash execution context (within a single eval). The issue never happens locally, regardless of whether standard streams are a tty or not. Digging any deeper would mean live debugging.