can we use variable inside another variable

amemyum · 11-10-2009, 06:18 AM

Hi,

I am facing this problem where I have declared the variable ($ProgramID) and again I'm callin this variable in another variable ($SOURCEPATH)

here the extract from my code:
SOURCEPATH=../sqa/$ProgramID/seatapps/app_dir

So, I called this variable SOURCEPATH the variable "ProgramID" does not get updated with the actual value.

thanks

David the H. · 11-10-2009, 07:05 AM

Please make sure to specify what platform you're referring to. I assume we're talking about bash scripting?

Yes, you can do it. Using variables to set other variables is a very common practice.

Your code should be working. I can't see any problems with it. Do make sure you aren't using single-quotes around the string, because that would keep the variable from expanding. I do suggest enclosing it in double-quotes though.

To see what your script is doing, you can use "set -x" and "set +x" to turn verbose output on and off, and will show you what substitutions are being made. A few echos liberally spaced around the code can also help.

Code:

set -x

ProgramID=123

echo "$ProgramID"

SOURCEPATH="../sqa/$ProgramID/seatapps/app_dir"

echo "$SOURCEPATH"

set +x

This works fine for me.
If you can, please post a longer sample of the code so we can see what's happening in context.

amemyum · 11-10-2009, 07:27 AM

thanks..
However, my problem is that the variable is set in another file and I'm trying to call the variable in another file and this way its not working

config.ini initializes the variable -> SOURCEPATH=../sqa/$ProgramID/seatapps/app_dir

month_files.sh calls-> cp $SOURCEPATH/*.air disks/seatapp/

thanks

forrestt · 11-10-2009, 07:35 AM

And how are you calling config.ini from month_files.sh?

Forrest

amemyum · 11-10-2009, 07:41 AM

The file config.ini is read by file named main.sh and through a function call the other file month_files.sh is used.

dunkar70 · 11-10-2009, 07:45 AM

The scope of a variable is limited to the file in which it is defined. In order to get that value, you need to do one of the following:
1. incorporate a way of passing the value from the external script
2. set an environment variable with the external script
3. incorporate the code from the other script

One way to pass the value is to have the source script return the value from a call like the example below. I have not tested this, but it should work...in theory. Anyone and everyone who knows better is free to correct me. The problem with this approach is that it may require you to modify the source script in which you are defining the variable.

script1:

Code:

#!/bin/bash
var1=SomeValue
return $var1

script2:

Code:

#!/bin/bash
var2=`/bin/bash script1`
echo $var2

Note: The command to define var2 is using back ticks (`) not single quotes.

Having said all that... unless you are creating a fairly large package, it may be simpler and safer to keep each script self-contained and independent of your other scripts. This way you do not need to worry about dependencies and breaking things if you have to modify one script.

David the H. · 11-10-2009, 07:50 AM

Well, no wonder then. It helps to include little details like that when diagnosing a problem, you know.

The more relevant information you provide at the beginning, the more likely you are to get help.

It's impossible to use a script to set a variable in the shell running above it. Each script you call runs in it's own subshell, and the variables set inside them are only available to that process and any further subprocesses it creates.

You'll probably have to either alter your first script so that it exports the value to a temporary file for the second script to read, or run the first script directly inside the second script, so that its output can be used directly.

dunkar70 · 11-10-2009, 07:55 AM

Quote:

Originally Posted by David the H.

You'll probably have to either alter your first script so that it exports the value to a temporary file for the second script to read, or run the first script directly inside the second script, so that its output can be used directly.

I generally prefer to avoid temporary files as they tend to make things messy if they are not deleted properly, overwrite existing temporary files, or collide with other people trying to do the same thing on the box. For complex scripts, they can also be difficult to debug if they are deleted or are using randomly generated names (to avoid overwriting an existing temp file).

Update: Of course, using environment variables has the same problems in addition to using additional memory.

amemyum · 11-16-2009, 06:19 AM

thanks david & dunkar...

evo2 · 11-16-2009, 06:45 AM

script1

Code:

#!/bin/bash
var1=SomeValue
echo $var1

script2

Code:

#!/bin/bash
var2=$(script1)
echo $var2

Or anther way

script1

Code:

var1=SomeValue

script2

Code:

#!/bin/bash
. script1
echo $var1

Or a third way.
script1

Code:

#!/bin/bash
export var1=SomeValue

script2

Code:

#!/bin/bash
echo $var1

Call this way

Code:

script1
script2

Evo2.

David the H. · 11-16-2009, 11:28 AM

No, that third way will not work, as has been explained already in this thread. Exporting the variable makes no difference. There's simply no way a script can set a variable outside its own subshell environment. Once the first script terminates, any variables set within it are lost, and are inaccessible from outside in any case (except through stdout or a similar redirection). Try it yourself and see.

PTrenholme · 11-16-2009, 11:58 AM

The dot, however, does run the script in the current context, and is used extensively by the system scripts to get parameter values into a running script. So evo2's second way is, I believe, the way to go.

You might also want to look at the exec function, and the differences between $(...) and ${...}, although the latter - in the ${!..} form - is used for referencing the value of a variable defined by the value of another variable. (I.e., "indirection.") It's "useful" for writing self-modifying bash scripts, if you have some need for that functionality.

catkin · 11-16-2009, 12:35 PM

A variable can be set in a calling script via the eval command if the called script writes a variable assignment. For example ...

script1.sh:

Code:

eval $(script2.sh)

script2.sh:

Code:

echo foo=bar

evo2 · 11-16-2009, 03:44 PM

Quote:

Originally Posted by David the H.

No, that third way will not work, as has been explained already in this thread. Exporting the variable makes no difference. There's simply no way a script can set a variable outside its own subshell environment. Once the first script terminates, any variables set within it are lost, and are inaccessible from outside in any case (except through stdout or a similar redirection). Try it yourself and see.

True. No need to try, just need to read what I typed :-)

Should have been:
script1

Code:

export var1=SomeValue

Run like

Code:

. scrpit1
script2

Evo2.