I beg to respectfully differ: both are great methods to shoot oneself into foot, even if i have to concede that your method is doing so with a nicer looking gun.

Perhaps the only reason to use such an indirect evaluation (regardless of using your construct or mine) is because the function doesn't know (at writing time) the variables true name. This establishes a sort-of passing by reference (instead of the usual passing by value).

To give an example for what i mean, if you have this code:

Code:

x=value
func "$x"

then inside the function you "know" the name of your received variable - $1:

Code:

func()
{
parm1="$1"

do_something "$parm1"
....
}

Whereas here:

Code:

x="value"
func x    # notice: variable name instead of value

func()
{
parm1=${!1}       # your way
eval parm1=\$$1  # my way

...
}

You have not the same kind of knowledge because you cannot expand $1 but have to expand what $1 expands to.

In languages such as C you pass around pointers to data (or, in FORTRAN, you pass by reference) because you want to manipulate the data statically across functions: one function creates a list and passes a pointer to it (instead of the copied structure) to another function which adds a new element. Both functions work on the same data instead of one calling the other with a copy of the original (which would be lost when the function returns).

But in scripting languages there is no such thing like pass by reference and there is no such thing as common, static data you can manipulate. You can try to dot-execute all your functions to get there, but this would most probably lead to desaster quite fastly. So there is no real application for this kind of "indirect evaluation" other than perhaps supporting bad design. I am sure that - by reformulating the problem - it would perhaps be possible to come up with a simpler and cleaner solution which will not rely on double dereferencing to get to a variables content.

And there is one more problem: if you look closely at the second variation with the double dereference you will notice that it relies on the existence of a variable named "x" which is defined outside, in the calling function. This is a violation against the rule of encapsulation: you should use at one level only what you defined on that level, not something from the background environment, because once this environment changes you are in deep kimchi.

bakunin