0

Im having trouble using a dynamic varaible, or variable within a variable.

Basically, a CI server has a bunch of environment variables set on a repo. They are doing multiple deploys from one repo, and based on the branch name, we read in the correct env variable, and echo back out the variable values in a config file to be used by application code later.

The application code only reads in one set of generic values, regardless of environemnt, for example DB_USERNAME

So, something like this...

CI Server ENV Variables
DEV_DB_USERNAME
STG_DB_USERNAME
PRD_DB_USERNAME
DEV_LAB_DB_USERNAME
STG_LAB_DB_USERNAME
PRD_LAB_DB_USERNAME

The Branch name can then be one of deploy-dev, deploy-stg, deploy-prd, or lab-dev, lab-stg, lab-prd.

So I have a bash script where I'm setting the branch name and ENV Var for testing that looks like:

#!/usr/bin/env bash

export TRAVIS_BRANCH="deploy-dev"
export DEV_DB_USERNAME="goodguy"

IFS="-" read TR_BRANCH DB_ENV TRAVIS_BRANCH <<< "$TRAVIS_BRANCH"
DB_ENV_UC=`echo "$DB_ENV" |tr '[:lower:]' '[:upper:]'`

if [[ ${TR_BRANCH} == "deploy" ]]
then
  DB_USERNAME=\$${DB_ENV_UC}_DB_USERNAME
else
  DB_USERNAME=\$${DB_ENV_UC}_LAB_DB_USERNAME
fi

echo "username is $DEV_DB_USERNAME"
echo "username is $DB_USERNAME"

first echo returns string: goodguy
second echo returns string $DEV_DB_USERNAME

How can I get the value of goodguy returned for $DB_USERNAME?

tman
  • 305
  • 1
  • 8
  • 20
  • I looked at the other question, and I'm not seeing how its a duplicate, because of the fact that I am trying to embed within the variable name, another variable. Im not making the connection, so assistance is appreciated – tman Jan 24 '18 at 15:42
  • Your code isn't an MCVE ([MCVE]); it is relatively hard to follow. You don't need the `read`; you could simply assign the value `dev` to `DB_ENV`. You don't need the conditional; you could simply assign to `DB_USERNAME`. You should drop the leading `$` from the value of `DB_USERNAME`, so it ends up containing just a name. As it's written, you get `DB_USERNAME="\$dev_DB_USERNAME"` or `DB_USERNAME="\$dev_LAB_DB_USERNAME"`, and there's no definition for any variable name starting `dev_`. However, given `DB_USERNAME=DEV_DB_USERNAME`, you'd use: `echo "${!DB_USERNAME}"`. – Jonathan Leffler Jan 24 '18 at 15:53
  • Ok, I was trying to provide a minimal example, that actually runs, that demonstrates what im trying to accomplish. The only thing that I left out was a conversion to uppercase for the ENV, i.e. dev to DEV. When you say I don't need the read, I will have to examine the value of $TRAVIS_BRANCH in some way to determine which branch is being acted on, for this example I was just setting them statically to test with. – tman Jan 24 '18 at 16:21
  • The problem from my perspective was the lack of V (verifiable) in the reproduction. The case mapping step was completely missing and the code shown couldn’t produce the claimed answer. Once that element of trust is broken, everything becomes fair game for criticism. The main answer is in the duplicate and my previous comment: don’t embed the `$` in the value of the variable holding the name and use `${!var}`. If you insist on the dollar sign, you’re living dangerously and need to investigate `eval echo $DB_USERNAME` — No, I deny it all; `eval` was never mentioned where children could hear it! – Jonathan Leffler Jan 24 '18 at 16:54
  • Ok, thats fair, thank you. I can update code if that makes sense, but seems like everything has been covered. Out of curiosity, why should one steer away from eval? – tman Jan 24 '18 at 17:06
  • I went ahead and added the uppercase conversion. – tman Jan 24 '18 at 17:09
  • The problem with `eval` is that it is dangerous — an extremely sharp knife that is trivially easy to misuse. If the string that is evaluated is not wholly under the control of the script, or contains user input that has not been rigorously scrutinized, it can lead to dramatic problems. Check the [Bash Guide](http://mywiki.wooledge.org/BashGuide) and [Bash FAQ](http://mywiki.wooledge.org/BashFAQ) — it's bound to be covered in there. – Jonathan Leffler Jan 24 '18 at 17:11
  • 1
    Since you have the answer you need (I believe), I suggest getting on with life using that information. With luck, you learned a few things today. – Jonathan Leffler Jan 24 '18 at 17:13

0 Answers0