Variable scope after exporting 1

[jones33]

Hi,

could somebody please advise me about the scope of variables in a bourne shell script in
the following situation:


If I have a script printName - just for simplicity

#!/bin/sh
VAR_NAME=$1
export $VAR_NAME

while [ true ]
do
echo $VAR_NAME
done


Now if I run this 3 times concurrently

./printName Leo
./printName Pat
./printName Al

Is there any danger of the variable VAR_NAME getting mixed up in the 3 scripts?

In practise this script wouldn't be run interactively. Instead it would be run by a cron job
and picking up a new name each time.

From what I understand when a variable is exported it is available to all scripts then run in the environment????

Would greatly appreciate some advice about this.

Thanks

 

[Ghodmode]

When you run something in a script, it runs inside of its own copy of the shell. So, there's no danger of the variables getting mixed up. In fact, you'll find that after running the script, the variable isn't even set when you type [tt]echo $VAR_NAME[/tt] at the command line. It's not even used in your current shell.

If you wanted to have a variable that was set in a script available to you outside of the script, you would need to source it. There is a built-in [tt]source[/tt] command available in the Bash shell, but most people just use its alias, which is just a dot ([tt].[/tt]). The dot also works in the Korn shell.

So, if I wanted [tt]VAR_NAME[/tt] avaialable to me, I would use

. printName

--
-- Ghodmode

Give a man a fish and he'll come back to buy more... Teach a man to fish and you're out of business.

 

[jones33]

Thank you very much Ghodmode

So when a variable is exported within a script is it only available to that script and all the scripts called from within that script?

 

[Ghodmode]

Hi jones,
You have it exactly right now. If you export a variable within a script, then call other scripts from within that script, the variable should be available to the other scripts.

A more conventional approach, though, is to source in a file that contains just variables. Consider it kind of like a configuration file. For example, if you have a some settings that you want all of your scripts to use, you might use these:

[purple]#!/bin/bash[/purple]
[blue]## config.sh[/blue]
export LOGDIR="$HOME/logs"
export FILEDATE=`date +"%d%b%Y_%H%M%S"` ## See 'man strftime'

[purple]#!/bin/bash[/purple]
[blue]## script1.sh[/blue]
. config.sh
LOGFILE="$LOGDIR/script1_${FILEDATE}_log.txt"

This might work even if you don't [tt]export[/tt] the variables. I'm not sure.

--
-- Ghodmode

Give a man a fish and he'll come back to buy more... Teach a man to fish and you're out of business.

 

[jones33]

Thanks Ghodmode

Okay I'm going to add another twist to this

Imagine we have 3 config files:

config1.sh contains "export VAR_NAME="Leo"
config2.sh contains "export VAR_NAME="Pat"
config3.sh contains "export VAR_NAME="Matt"

Now if we have the script printName

#!/bin/sh
VAR_SCRIPT=$1
. $VAR_SCRIPT

while [ true ]
do
echo $VAR_NAME
done

If we run this concurrently with
./printName config1.sh
./printName config2.sh
./printName config3.sh

Is there now a possibility of the names getting mixed up in each of the scripts?

Is it possible to call an external config file with variables in a script and keep the values retrieved from that config file local to the instance of the script that called it?

Many thanks again! This is the first time I have had to create a script with multiple instances of it running, each with a different config file.

 

[Ghodmode]

Nope, it still won't get mixed up because each script is still executed within its own shell. So, in your example, the first execution will show [tt]Leo[/tt], the second one will show [tt]Pat[/tt], and the third one will show [tt]Matt[/tt].

--
-- Ghodmode

Give a man a fish and he'll come back to buy more... Teach a man to fish and you're out of business.

 

[jones33]

Thanks Ghodmode,

Earlier you mentioned that

"If you wanted to have a variable that was set in a script available to you outside of the script, you would need to source it. There is a built-in source command available in the Bash shell, but most people just use its alias, which is just a dot (.). The dot also works in the Korn shell.
"

In the last script printName wouldn't am I not sourcing the config file thereby making it available outside of the script in which it was called???

Or maybe I don't fully understand what you mean by "sourcing" a script.

Many Thanks for your help!

 

[Ghodmode]

When you execute a script, it is actually executed within it's own copy of the shell. In [tt]printName[/tt], you are sourcing [tt]config1.sh[/tt] which makes the variables set in [tt]config1.sh[/tt] available outside of that script within the context of [tt]printName[/tt].

When you source the config file, you make its variables available outside of the config file and within the current shell. Since you're sourcing the config file within a script, the variables are available within the copy of the shell that executing the script creates.

Likewise, if you source your config file script from the command line, its variables will become available outside of the config file script and within the current shell: the interactive one you're typing at.

I think you've progressed to the point where explanation will not serve you as well as exercise. Type in a few practice scripts and echo variables that you set. This way, you'll have a better understanding of variable scope.

--
-- Ghodmode

Give a man a fish and he'll come back to buy more... Teach a man to fish and you're out of business.

 

[SamBones]

In your original script, the lines...

VAR_NAME=$1
export $VAR_NAME

...aren't doing what you think. That [tt]export[/tt] command is NOT exporting the variable "[tt]VAR_NAME[/tt]". It's exporting what "[tt]VAR_NAME[/tt]" is assigned to. This is because the dollar sign translated the variable, then does the export.

So, your examples are exporting variable called "Leo", "Pat", and "Al".

It should be...

VAR_NAME=$1
export VAR_NAME    # No dollar sign