What is the difference between executing a bash script and sourcing a bash script?

Question

What is the difference between executing a bash script like A and sourcing a bash script like B?

A
>./myscript

B
>source myscript

Answer 1

Short answer: sourcing will execute the commands in the current shell, executing will create a new shell and execute the commands there.

Example

Consider myscript.sh with following content:

#!/bin/sh
# demonstrate setting a variable
echo "foo: "$(env | grep FOO)
export FOO=foo
echo "foo: "$(env | grep FOO)
# demonstrate changing of working directory
echo "PWD: "$PWD
cd somedir
echo "PWD: "$PWD

Before we execute the script first we check the current environment:

$ env | grep FOO
$ echo $PWD
/home/lesmana

The variable FOO is not defined and we are in the home directory.

Now we execute the file:

$ ./myscript.sh
foo:
foo: FOO=foo
PWD: /home/lesmana
PWD: /home/lesmana/somedir

Check the environment again:

$ env | grep FOO
$ echo $PWD
/home/lesmana

The variable FOO is not set and the working directory did not change.

The script output clearly shows that the variable was set and the directory was changed. Where did the changes go? The changes were made in a new shell. The current shell spawned a new shell to execute the script. The script is executing in the new shell and all changes to the environment take effect in the new shell. After the script is done the new shell is destroyed. All changes to the environment in the new shell are destroyed with the new shell. Only the output text is printed in the current shell.

Now we source the file:

$ source myscript.sh
foo:
foo: FOO=foo
PWD: /home/lesmana
PWD: /home/lesmana/somedir

Check the environment again:

$ env | grep FOO
FOO=foo
$ echo $PWD
/home/lesmana/somedir

The variable FOO is set and the working directory has changed.

Sourcing the script does not create a new shell. All commands are executed in the current shell and changes to the environment take effect in the current shell.

Note that in this simple example the output of executing is the same as sourcing the script. This is not necessarily always the case.

Another demonstration

Consider following script pid.sh:

#!/bin/sh
echo $$

($$ is a special variable which contains the PID of the current running shell process)

First print the pid of the current shell:

$ echo $$
25009

Source the script:

$ source pid.sh
25009

Execute the script, note the PID:

$ ./pid.sh
25011

Source again:

$ source pid.sh
25009

Execute again:

$ ./pid.sh
25013

You can see that sourcing the script runs in the same process while executing the script creates a new process everytime. That new process is the new shell which was created for the execution of the script. Sourcing the script does not create a new shell and thus the PID stays the same.

Summary

Both sourcing and executing the script will process the commands in the script line by line, as if you typed those commands by hand line by line.

The differences are:

• When you execute the script you are opening a new shell, type the commands in the new shell, copy the output back to your current shell, then close the new shell. Any changes to environment will take effect only in the new shell and will be lost once the new shell is closed.
• When you source the script you are typing the commands in your current shell. Any changes to the environment will take effect and stay in your current shell.

Answer 2

Executing a script runs it in a separate child process, i.e., a separate instance of shell is invoked to process the script. This means that any environment variables etc., defined in the script can't be updated in the parent (current) shell.

Sourcing a script means that it is parsed and executed by the current shell itself. It's as if you typed the contents of the script. For this reason, the script being sourced need not be executable. But it has to be executable if you're executing it of course.

If you have positional arguments in the current shell, they're unchanged.

So if I have a file a.sh containing:

echo a $*

and I do:

$ set `date`
$ source ./a.sh

I get something like:

a Fri Dec 11 07:34:17 PST 2009

Whereas:

$ set `date`
$ ./a.sh

gives me:

a

Hope that helps.

Answer 3

Sourcing you get all the extra variables defined in the script.
So if you have configs or function definitions you should source and not execute. Executions are independent from the parents environment.

Answer 4

sourcing is essentially the same as typing each line of the script in at the command prompt one at a time...

Execution starts a new process and then runs each line of the script, only modifying the current environment by what it returns.

Answer 5

In addition to above, executing the script as ./myscript requires execute permission for file myscript while sourcing does not require any execute permission. That is why chmod +x myscript is not required before source myscript

Answer 6

If I recall correct, executing the script runs the executable in the #! line with the script file as an argument (typically starting a new shell and effectively sourcing the script into the new shell, as with #!/bin/sh);
whereas, sourcing the script executes each line in your current shell environment, which is useful to mutate your current shell (for example, providing a way to define shell functions and export environment variables).