I have multiple Amazon EC2 accounts and want to quickly be able to switch variables, such as $EC2_HOME, using a script.

I have have a shell script set up like this:

export EC2_HOME=/home/me/.ec2
echo $EC2_HOME

When I run the script I know that EC2_HOME is set, but I thought that using export would make the variable stick around after the script completed. It does not, as running echo $EC_HOME does not show anything.

I know this must be very rudimentary Linux scripting knowledge, but I don't know it. I tried looking for related questions without luck - so my apologies if this is a duplicate.


4 Answers 4


You should source your script, with

. ./script


source ./script
  • 30
    the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell. Commented Jan 27, 2012 at 20:32
  • 2
    @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?
    – Patryk
    Commented Feb 21, 2012 at 13:03
  • 8
    @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.
    – enzotib
    Commented Feb 21, 2012 at 13:24
  • 1
    While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?
    – 71GA
    Commented Sep 27, 2014 at 13:37
  • 1
    @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.
    – enzotib
    Commented Sep 27, 2014 at 13:52

When you run a script it gets its own shell and its own environment, which disappear again as soon as the script is finished. To keep the environment variables around, source the script into your current shell:

$ source ./a.sh

or equivalently (but a little more portably) use the POSIX dot command:

$ . ./a.sh

Then the definitions will be put into your current shell's environment and be inherited by any programs you launch from it.

To be closer to running a script, . a.sh will find a.sh by searching the directories in the PATH environment variable.

There are some subtleties in how these behave, and whether . and source are the same (or present at all). . ./a.sh will definitely behave the same in every POSIX-compatible shell, but source and ., and . a.sh and . ./a.sh, can vary. For Bash source and . are the same in all cases; for zsh source always checks the current directory first; ksh is essentially similar.

If the script name is given as a path (containing a /), that path is used directly in all cases. The most portably reliable thing to do is . ./script or . /path/to/script.


Just for record.

If you want run script from internet which exports env to system

you can use following format

source <(curl -s -L https://raw.githubusercontent.com/iamwwc/wwcdocker/master/install.sh)

For example:

source <(curl -s -L https://example.com/install.sh)
  • 2
    Looks dangerous but useful if you trust that script! Commented Oct 10, 2019 at 15:55


exec ./script

The exec command runs the script in the current shell without starting non interactive shell.

  • This will replace the shell with the script. i.e. you loose your shell after running this command
    – smac89
    Commented May 3, 2021 at 18:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .