This question already has answers here:
Does variable=$(...) store the command or the result of the command in POSIX sh
(3 answers)
Closed 2 years ago.
In my .bashrc I'm setting a bash variable to the output of a script
export FOO=`/home/jist/tools/lookup1.pl`
This works great except that the output of that script can change during the day (mainly depending on if I'm on the company's VPN or not). So when I do something with the variable, I want it to re-execute the script and get the updated value. I have no idea how to do this? Can someone please help?
Thanks in advance.
As described in a comment by William:
Make it a function emitting a refreshed value on stdout instead of a variable and always access it as $(FOO)
That means:
# create the function: put this in your .bashrc
FOO() { /home/jist/tools/lookup1.pl "$#"; }
# use the function and store its output: do this whenever you want the current result
currentFooResult=$(FOO)
# or, to just print the result to stdout:
FOO
Related
This question already has answers here:
Source files in a bash script
(2 answers)
Can I export a variable to the environment from a Bash script without sourcing it?
(13 answers)
Closed 2 years ago.
Here is what I have:
script_1.sh
echo "HELLO FROM script_1.sh"
./scripts/script_2.sh
echo $MY_VARIABLE
script_2.sh
echo "HELLO FROM script_2.sh"
export MY_VARIABLE="MY_VALUE"
Here is what it logs when I run script_1.sh:
HELLO FROM script_1.sh
HELLO FROM script_2.sh
"" // EMPTY LINE INSTEAD OF "MY_VALUE"
What am I doing wrong?
Variables are exported from a parent to a child, not vice versa. script_2.sh is called in a different shell whose environment doesn't propagate back to the parent shell.
Source the script (using the .) to call it in the same shell. You then don't even need to export the value.
. ./scripts/script_2.sh
environment variables are inherited down the call chain. they are not returned up to the caller.
in other words: a called script might inherit the variables of the caller. but the caller will not get the variables of the called script.
in you simple example the easiest solution is to "source the script"
. ./scripts/script_2.sh
(the dot is the command to source a script)
sourcing is not a new step in the call chain. instead the sourcer and sourcee share the same environment. for more explanation on the difference of executing and sourcing see here: https://superuser.com/questions/176783/what-is-the-difference-between-executing-a-bash-script-vs-sourcing-it/176788#176788
there are other options but they are more complicated and error prone. it seems that you are starting to learn shell scripting. so learn the difference of sourcing and executing and the implication on the environment for now. if you need other options later then come back and ask another question.
This question already has answers here:
Pass all variables from one shell script to another?
(7 answers)
Closed 3 years ago.
OS: Ubuntu 18.04
Bash
I am trying to get one shell script to pass variables to another script and execute it. Here's what I tried:
mainscript.sh
#!/bin/bash
# Master script
SUBSCRIPT1_PATH=~/subscript1.sh
test_string="The cat ate the canary"
(exec "$SUBSCRIPT1_PATH")
subscript1.sh:
#!/bin/bash
# subscript1.sh
echo $test_string
But, when I do:
bash mainscript.sh
I get nothing. Any ideas on how to do this?
Shell variables are by default not visible in child processes. To pass them to children use the export keyword:
#!/bin/bash
# Master script
SUBSCRIPT1_PATH=~/subscript1.sh
export test_string="The cat ate the canary"
(exec "$SUBSCRIPT1_PATH")
This question already has answers here:
Bash variable scope
(7 answers)
Closed 4 years ago.
I am working in Ubuntu Shell, but i want it to work for UNIX also.
Here is my code:
#!/bin/bash
func()
{
x=42
}
x=9
func
echo $x
Why is global x changed to 42 when i changed only local variable x
Is in unix different rule for variable scopes?
Is there a method how to set return value from func to global variable, which can be used later in code?
Thank you!
First, you're not programming Linux; you're actually writing a function for the shell program called bash. Enter info bash on the command line to get documentation for that. For any version of Unix, what happens on the command line depends on which type of shell you're running (there are many; bash is the default for most Linux systems).
Variables in a function which are not declared are global by default. As the comment stated, you can use local to mark the variable as local to the function.
This question already has answers here:
How can I make bash treat undefined variables as errors?
(2 answers)
Closed 6 years ago.
I work with a lot of shell scripts that use bash variables. So, for example, I might have a script like this:
option1="-blah_blah"
option2="-yada_yada"
option3="-whatever"
...
option99="-something_else"
./myCommand "$option1 $option12 $option97 $option45"
I am constantly editing that last command to run various engineering tests. The problem is, sometimes I misspell a variable. In that case, Bash simply substitutes an empty string, and my command does the wrong thing silently.
Is there a way to have Bash throw an exception when I try to use a variable that is not defined?
Use:
set -e # Stop on error. I can't believe that this is not default.
set -u # Stop if trying to use un-initialized variables.
This question already has an answer here:
Best way to set environment variables in calling shell
(1 answer)
Closed 8 years ago.
I have a script "set_var.sh" written like this
#!/bin/bash
export NAME=release
export ROOT=/Volumes/name/dev/release
but if I run this set_var.sh from terminal, afterward I issue set command to check variables I could not find NAME and ROOT var be set.
I am wondering what is wrong in my case.
it was set in sub-shell.
you need
source set_var.sh
If you simply run set_var.sh, it runs in its own shell which exits, losing the variables that were set.
If you want to change variables in your interactive shell, you can use:
source set_var.sh
or the shorthand,
. set_var.sh
This will execute the lines of the script as if they were typed into your interactive shell.
Note that when you "source" a file this way, it does not require the "shebang" on the first line.
Note also that this is feature exists in Bourne shell as well, but only in the short-form version.