Hi, this is pathetic I know:

CUSTOMER_REFS_ZZ="ZZ ZEE ZULU ZEBRA"
echo $CUSTOMER_REFS_ZZ
ZZ ZEE ZULU ZEBRA

CUSTOMER_SHORT_NAME="ZZ"
echo $CUSTOMER_SHORT_NAME
ZZ

CUSTOMER_REFS="CUSTOMER_REFS_$CUSTOMER_SHORT_NAME"
echo $CUSTOMER_REFS
CUSTOMER_REFS_ZZ

echo $CUSTOMER_REFS_ZZ
ZZ ZEE ZULU ZEBRA

I would like a one liner something like

echo $`echo $CUSTOMER_REFS`

to give

ZZ ZEE ZULU ZEBRA

but all it gives is

$CUSTOMER_REFS_ZZ

i.e. I don't want to refer to the 'inner' $CUSTOMER_REFS_ZZ variable directly.

Help would be MUCH appreciated. Name your single malt!

Martin

You're looking for "eval"

http://www.tldp.org/LDP/abs/html/ivr.html

1 members found this post helpful.

suicidaleggroll - THANK YOU!

Wow! It'll take me a while to follow that ... I am OLLLLDDD and dumb and need the bathroom and its 18:20 here already and then I HAVE to get home.

So bear with me not implementing it until tomorrow probably.

Kind regards - Martin

Do not use "eval". It is very dangerous to use unless you have checked that the strings do not contain any characters that are special to the shell. What you want is variable indirection:

1 members found this post helpful.

rknichols ... I haven't been to the bathroom but it was worth it! Thank you.

If you want to know more about eval you can also look here

As it is also fraught with some dangers of what people could force your program to do if the know eval is around and not being used correctly, I generally try to stay clear.

My normal first question would be, what benefit do you get from being able to combine variable names in this way? (I also find it a little odd (funny) as well because when talking with programmers
in other languages this requirement rarely if ever actually comes up, yet many people try to do it with bash .. oh well)

Could your solution perhaps be solved using associative arrays instead? (see earlier in the page of the link above for details)

1 members found this post helpful.

Yes it is dangerous IF you're getting the variable name from user input from users you don't trust, but you ALWAYS need to be careful when you're reading and using user input from users you don't trust, regardless of the language or what you're doing with the information. There's no need to jump into panic mode unless this is one of those situations.

1 members found this post helpful.

The issues are more than just deliberate malice. You have to absolutely sure of what can show up in those fields. You can have a script that runs fine, then perhaps a short name "AT&T" gets put in the database and the ampersand makes your "eval" do something strange. A string with an embedded single quote would also make your script fail, and protecting against these with quoting gets complicated because strings are being parsed twice by the shell. Using "eval" when a simpler, more direct, and much safer alternative is available is just misguided.

1 members found this post helpful.

Same with any script. 99.9999% of the solutions to questions posted on this forum use syntax that would break down if an ampersand or quote made its way into a variable. You can't protect against everything.

It would make both approaches fail...they would just fail in different ways. If an ampersand or quote gets into the variable that you're using to build up a dynamic variable name, the script is going to fail no matter what method you use to build that dynamic variable name.

I'd argue that this approach in general is misguided, and there is almost always a better, cleaner, and more robust way of attacking the problem than dynamically building up a variable name using other variables. If it MUST be done, then yes ${!var} (if it's available) is a better way of getting to the result than eval, but ${!var} is not always an option, and its use would reduce the code's portability.

1 members found this post helpful.