What better way to use same variable in two different bash scripts?
Simple example:
./set.sh 333
./get.sh
> 333
./set.sh 111
./get.sh
> 111
And how initialize that variable first time?
UPD:
$ cat get.sh
echo "$var"
$ cat set.sh
export var="$1"
$ chmod +x set.sh get.sh
$ source set.sh
$ ./set.sh u
$./get.sh
$ source ./set.sh 2
$ ./get.sh
2
You can have your scripts as:
cat set.sh
export var="$1"
cat get.sh
echo "$var"
chmod +x set.sh get.sh
Then call them:
. ./set.sh 333
./get.sh
333
Please note that . ./set.sh OR source ./set.sh is called sourcing in the script which makes sure that set.sh is executed without creating a sub-shell and variables set in that script are accessible in the other scripts.
What you need to understand is the lifetime of a shell variable (or an environment variable as you are using).
When you run a sub-shell, you are running a child process of the shell, and any shell variables that you set exist for the lifetime of the script. Any environment variables (shell variables are "promoted" to environment variable by the use of export) are copied into the environment of the child process - so changes to environment variables in a child process have NO effect on the value in the parent process.
So what you need to use is source which executes the contents of the script in the current shell (no sub-shell is spawned). Always source set.sh and you should be OK
You have to store that number in a file.
A called shell script is not able to change the variables of the calling shell.
Another way is to source the shell script instead of running it as a separate process.
But maybe you should explain why you think, that you need that feature. Maybe some totally different solution is even better.
Related
I have 2 bash scripts:
set.sh
export MYVAR="MYVALUE"
get.sh
echo "MYVAR: $MYVAR"
usage
> ./set.sh && ./get.sh
I'm trying to share the variable among the scripts. The real code is more complicated and involves more than 2 scripts, so I cannot call the second script from the first one like that
export MYVAR="MYVALUE"
./get.sh
I can think of several tries:
Via third script: Use a third environment script and source it in set.sh and get.sh. Probably you can't do that because set.sh has a lot of logic.
Via code: source set.sh in get.sh and add specific logic to set.sh to recognize if set.sh is sourced or executed.
Via pipe: Have you thought about using a pipe for interprocess communication between set.sh and get.sh? You could send MYVAR from set.sh to get.sh through the pipe, and only start executing in get.sh once this information has arrived.
Via file: Use a file to transmit the value of MYVAR by writing it from set.sh to the file and reading from the file in get.sh.
Via output: Write MYVAR to the output in set.sh and consume (or parse) the output of set.sh in get.sh.
Set them as arguments to the scripts
./set.sh "$MYVAR" && ./get.sh "$MYVAR"
I have a shell script that sets a variable. I can access it inside the script, but I can't outside of it. Is it possible to make the variable global?
Accessing the variable before it's created returns nothing, as expected:
$ echo $mac
$
Creating the script to create the variable:
#!/bin/bash
mac=$(cat \/sys\/class\/net\/eth0\/address)
echo $mac
exit 0
Running the script gives the current mac address, as expected:
$ ./mac.sh
12:34:56:ab:cd:ef
$
Accessing the variable after its created returns nothing, NOT expected:
$ echo $mac
$
Is there a way I can access this variable at the command line and in other scripts?
A child process can't affect the parent process like that.
You have to use the . (dot) command — or, if you like C shell notations, the source command — to read the script (hence . script or source script):
. ./mac.sh
source ./mac.sh
Or you generate the assignment on standard output and use eval $(script) to set the variable:
$ cat mac.sh
#!/bin/bash
echo mac=$(cat /sys/class/net/eth0/address)
$ bash mac.sh
mac=12:34:56:ab:cd:ef
$ eval $(bash mac.sh)
$ echo $mac
12:34:56:ab:cd:ef
$
Note that if you use no slashes in specifying the script for the dot or source command, then the shell searches for the script in the directories listed in $PATH. The script does not have to be executable; readable is sufficient (and being read-only is beneficial in that you can't run the script accidentally).
It's not clear what all the backslashes in the pathname were supposed to do other than confuse; they're unnecessary.
See ssh-agent for precedent in generating a script like that.
I am executing a perl script on windows, using a batch script.
I am setting below variable in batch script:
SET PATH_VAR=C:\Users\
I am able to access PATH_VAR in perl as below:
my $path1 = $ENV{'PATH_VAR'}
I would like to also export environment variables set in perl to batch. Like the inverse of what I am doing now.
Is there a way to do that?
PS:
I tried this, but it doesn't work:
$ENV{'PATH_Z'}="Hello World";
Changes to environment variables can not effect the parent process, it's part of how they work, so nothing you do in the Perl script can change the environment variables of the batch script. However any child process, started with exec(), system() or `` will see the changes you made in the Perl script.
The only way to do this is to have the Perl script output shell statements, and for the shell to evaluate the output.
Bash example:
$ export FOO=123
$ echo $FOO
123
$ perl -e 'print "export FOO=456\n"' ; echo $FOO
123
$ $(perl -e 'print "export FOO=789\n"') ; echo $FOO
789
Edit: I see OP is using Windows, so this answer doesn't apply :-(
I have seen below two lines in a shell script.
Im new to unix scripting, what is the use of setting this?
PATH=$PATH:/bin:/usr/bin:/usr/sbin:/sbin:/etc:/usr/ucb:/usr/ccs/bin:/usr/local/bin
export PATH
Thanks in advance
If you export something (in bash anyway which I assume is your shell), it will mark that something to be available in subsequently executed commands.
$ FOO=1 # Set the variable
$ echo $FOO # Check the value
1
$ bash # New shell here.
$ echo $FOO # No value since it's not exported
$ exit # Quit the subshell
$ export FOO # Export it
$ bash
$ echo $FOO # It has a value now
1
export is a shell builtin for bash so doing a help export will give you more information on it.
Explicitly exporting the PATH doesn't hurt but generally has no effect as the PATH variable is almost certainly already marked as exported when you launch a shell script.
This question already has answers here:
Defining a variable with or without export
(15 answers)
Closed 3 years ago.
As far as I can tell, variable assignment is the same whether it is or is not preceded by "export". What's it for?
Exported variables such as $HOME and $PATH are available to (inherited by) other programs run by the shell that exports them (and the programs run by those other programs, and so on) as environment variables. Regular (non-exported) variables are not available to other programs.
$ env | grep '^variable='
$ # No environment variable called variable
$ variable=Hello # Create local (non-exported) variable with value
$ env | grep '^variable='
$ # Still no environment variable called variable
$ export variable # Mark variable for export to child processes
$ env | grep '^variable='
variable=Hello
$
$ export other_variable=Goodbye # create and initialize exported variable
$ env | grep '^other_variable='
other_variable=Goodbye
$
For more information, see the entry for the export builtin in the GNU Bash manual, and also the sections on command execution environment and environment.
Note that non-exported variables will be available to subshells run via ( ... ) and similar notations because those subshells are direct clones of the main shell:
$ othervar=present
$ (echo $othervar; echo $variable; variable=elephant; echo $variable)
present
Hello
elephant
$ echo $variable
Hello
$
The subshell can change its own copy of any variable, exported or not, and may affect the values seen by the processes it runs, but the subshell's changes cannot affect the variable in the parent shell, of course.
Some information about subshells can be found under command grouping and command execution environment in the Bash manual.
it makes the assignment visible to subprocesses.
$ foo=bar
$ bash -c 'echo $foo'
$ export foo
$ bash -c 'echo $foo'
bar
Well, it generally depends on the shell. For bash, it marks the variable as "exportable" meaning that it will show up in the environment for any child processes you run.
Non-exported variables are only visible from the current process (the shell).
From the bash man page:
export [-fn] [name[=word]] ...
export -p
The supplied names are marked for automatic export to the environment of subsequently executed commands.
If the -f option is given, the names refer to functions. If no names are given, or if the -p option is supplied, a list of all names that are exported in this shell is printed.
The -n option causes the export property to be removed from each name.
If a variable name is followed by =word, the value of the variable is set to word.
export returns an exit status of 0 unless an invalid option is encountered, one of the names is not a valid shell variable name, or -f is supplied with a name that is not a function.
You can also set variables as exportable with the typeset command and automatically mark all future variable creations or modifications as such, with set -a.