In order to export out the VAR variable first, the most logical and seemly working way is to source the variable:

. ./export.bash 

or

source ./export.bash 

Now when echoing from the main shell, it works:

echo $VAR HELLO, VARIABLE 

We will now reset VAR:

export VAR="" echo $VAR 

Now we will execute a script to source the variable then unset it:

./test-export.sh HELLO, VARIABLE -- . 

The code: file test-export.sh

#!/bin/bash # Source env variable source ./export.bash # echo out the variable in test script echo $VAR # unset the variable unset VAR # echo a few dotted lines echo "---" # now return VAR which is blank echo $VAR 

Here is one way:

Please note: The exports are limited to the script that execute the exports in your main console - so as far as a cron job I would add it like the console like below... for the command part still questionable: here is how you would run in from your shell:

On your command prompt (so long as the export.bash file has multiple echo values)

IFS=$'\n'; for entries in $(./export.bash); do export $entries; done; ./v1.sh HELLO THERE HI THERE 

File cat v1.sh

#!/bin/bash echo $VAR echo $VAR1 

Now so long as this is for your usage - you could make the variables available for your scripts at any time by doing a Bash alias like this:

myvars ./v1.sh HELLO THERE HI THERE echo $VAR . 

Add this to your .bashrc file:

function myvars() { IFS=$'\n'; for entries in $(./export.bash); do export $entries; done; "$@"; for entries in $(./export.bash); do variable=$(echo $entries|awk -F"=" '{print $1}'); unset $variable; done } 

Source your .bashrc file and you can do like the above any time...

Anyhow back to the rest of it...

This has made it available globally then executed the script...

Simply echo it out and run export on the echo!

File export.bash

#!/bin/bash echo "VAR=HELLO THERE" 

Now within script or your console run:

export "$(./export.bash)" 

Try:

echo $VAR HELLO THERE 

Multiple values so long as you know what you are expecting in another script using the above method:

File export.bash

#!/bin/bash echo "VAR=HELLO THERE" echo "VAR1=HI THERE" 

File test-export.sh

#!/bin/bash IFS=$'\n' for entries in $(./export.bash); do export $entries done echo "round 1" echo $VAR echo $VAR1 for entries in $(./export.bash); do variable=$(echo $entries|awk -F"=" '{print $1}'); unset $variable done echo "round 2" echo $VAR echo $VAR1 

Now the results

./test-export.sh round 1 HELLO THERE HI THERE round 2 . 

And the final final update to auto assign, read the VARIABLES:

./test-export.sh Round 0 - Export out then find variable name - Set current variable to the variable exported then echo its value $VAR has value of HELLO THERE $VAR1 has value of HI THERE round 1 - we know what was exported and we will echo out known variables HELLO THERE HI THERE Round 2 - We will just return the variable names and unset them round 3 - Now we get nothing back 

The script:

File test-export.sh

#!/bin/bash IFS=$'\n' echo "Round 0 - Export out then find variable name - " echo "Set current variable to the variable exported then echo its value" for entries in $(./export.bash); do variable=$(echo $entries|awk -F"=" '{print $1}'); export $entries eval current_variable=\$$variable echo "\$$variable has value of $current_variable" done echo "round 1 - we know what was exported and we will echo out known variables" echo $VAR echo $VAR1 echo "Round 2 - We will just return the variable names and unset them " for entries in $(./export.bash); do variable=$(echo $entries|awk -F"=" '{print $1}'); unset $variable done echo "round 3 - Now we get nothing back" echo $VAR echo $VAR1 

Execute

set -o allexport 

Any variables you source from a file after this will be exported in your shell.

source conf-file 

When you're done execute. This will disable allexport mode.

set +o allexport 

I found an interesting and neat way to export environment variables from a file:

In file env.vars:

foo=test 

Test script:

eval `cat env.vars` echo $foo # => test sh -c 'echo $foo' # => export eval `cat env.vars` echo $foo # => test sh -c 'echo $foo' # => test # a better one. "--" stops processing options, # key=value list given as parameters export -- `cat env.vars` echo $foo # => test sh -c 'echo $foo' # => test 

Another workaround that, depends on the case, it could be useful: creating another bash script that inherits the exported variable. It is a particular case of Keith Thompson's answer, will all of those drawbacks.

File export.bash:

# !/bin/bash export VAR="HELLO, VARIABLE" bash 

Now:

./export.bash echo $VAR 

The answer is no, but for me I did the following

The script:

myExport

#! \bin\bash export $1 

An alias in my .bashrc file:

alias myExport='source myExport' 

Still you source it, but maybe in this way it is more useable and it is interesting for someone else.

Export environment variables using script file

Problem:
When you run a script, it executes in a child shell and returns back to the parent shell after execution. Exporting variables only works down the child shells, you can't export a child shell's variable back to the parent shell.

Solution:
From your script file invoke a child shell along with variables that you want to export, this will create a new child shell with your variables exported.

script.sh ->

bash -c 'export VAR=variable; exec bash' 

: : CIPH3R

Maybe you can add a function in ~/.zshrc or ~/.bashrc.

# set my env [ -s ~/.env ] && export MYENV=`cat ~/.env` function myenv() { [[ -s ~/.env ]] && echo $argv > ~/.env && export MYENV=$argv } 

Because of the use of a variable outside, you can avoid the use of a script file.

simple naive approach that works:

script 1:

echo "something" > /tmp/myvar

script 2:

myvar=$(cat /tmp/myvar)

If you want to set a variable for the calling shell there is a robust approach using c unix sockets. The result will be tested like this:

$ ./a.out & [1] 5363 $ ./b.out 123;a=`./b.out`;echo ${a} 123 [1]+ Done ./a.out 

See a.c, b.c, and a.h from my github.

I don't think this can be done, but I found a workaround using alias. It will only work when you place your script in your scripts directory. Otherwise your alias will have an invalid name.

The only point to the workaround is to be able to have a function inside a file with the same name and not have to bother sourcing it before using it. Add the following code to file ~/.bashrc:

alias myFunction='unalias myFunction && . myFunction && myFunction "$@"' 

You can now call myFunction without sourcing it first.

This workaround is somehow hinted to elsewhere, but maybe not that clearly:

In your script, after setting the variable, start a new shell, rather than return.

My use cases is that I have a number of terminals open and in some of them I want some values for some variables, while in others I want other values.

As using source may be harder to remember, a small advantage of this approach is when it takes a while to realize that you forgot to use source, and you have to start from scratch.

(For me it makes more sense to use source script, as the missing variables are noticed immediately.)

I had similar problem calling ssh-agent -s in a script called by option -e in rsync.

In the script eval $(ssh-agent -s) don't preserve the environment variables for the next call.

rsync -e 'source ssh-check-agent.sh -p 8022' does not work, so I made a workaround. In the script I saved the variables in a temporal file after call ssh-agent like:

echo "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK;" > /tmp/ssh-check-agent.vars echo "export SSH_AGENT_PID=$SSH_AGENT_PID;" >> /tmp/ssh-check-agent.vars 

and after in the script that calls rsync (backup.sh) I call:

source /tmp/ssh-check-agent.vars 

The problem is that script that calls rsync must be called by source (source backup.sh).

I know that is not the question (I use two times source), but I put here if someone has similar problem with rsync.

Others have already answered your question, but here's a little advice. Since you have to call the script with a leading dot so that set variables remain valid for the calling shell, I solved this by having the script always inform me if I didn't start it with a leading dot. This way I am reminded to use a leading dot.

#!/bin/sh if [ $0 = "NAME_OF_SCRIPT_WITH_ITS_PATH" ] then # If the script was called without a leading dot, print a hint. echo "Important:" echo " This script must be called with a leading dot." echo " Otherwise, the environment variables will not be added to the calling shell." else # If the script was called with a leading dot, set the environment variables. # In this case $0 corresponds to the name of your shell. # For example $0 is "/bin/bash" for bash. export FOO=TRUE export BAR=FALSE echo "Environment variables have been set." fi 

NAME_OF_SCRIPT_WITH_ITS_PATH must be replaced with the name of your script file and its path. Basically it is the value that a command like echo $0 would output inside the script if the script is not run with a leading dot.

Let's say I want to have a command that sets an environment varible FOO in the current shell. The example just shows the process, it's not the best way to achieve the same result.

I put the following in a file called foo.sh:

foo() { local value="${1:-bar}" source <(echo "export FOO=$value") } export -f foo 

Then I can run the following commands:

$ source foo.sh $ foo && echo $FOO bar $ foo baz && echo $FOO baz 

If I want the command to be generally available, I could put it in my shell's rc file, e.g. .bashrc.

A slightly more involved example could be something like the following that sets my AWS_PROFILE environment variable to something I chose from the list of valid values. The example requires the fzf command to be installed.:

list-profiles() { local filter="${1:-}" aws configure list-profiles | sort -f | grep -v ^default$ | grep "$filter" } set-profile() { local query="${1:+--query $1}" if RES=$(list-profiles | fzf --preview="" -1 $query); then echo "export AWS_PROFILE=$RES" fi } sp() { source <(set-profile "${1:-}") && aws sts get-caller-identity } export -f sp 

If I run sp without parameters, it will show a list of profiles to choose from. If I run sp foo it will only show profiles that contain foo in their name. If there is only one valid result, it will automatically pick that one.