What is the difference between executing a Bash script vs sourcing it?



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

> ./myscript

> source myscript

Scottie T

Posted 2009-12-11T15:24:17.607

Reputation: 3 221

You might read this: https://bash.cyberciti.biz/guide/Source_command

– ERU – 2019-01-08T12:26:16.743



Sourcing a script will run the commands in the current shell process.

Executing a script will run the commands in a new shell process.

Use source if you want the script to change the environment in your currently running shell. use execute otherwise.

If you are still confused, please read on.


To clarify some common confusion about the syntax to execute and the syntax to source:


This will execute myscript provided that the file is executable and located in the current directory. The leading dot and slash (./) denotes the current directory. This is necessary because the current directory is usually not (and usually should not be) in $PATH.


This will execute myscript if the file is executable and located in some directory in $PATH.

source myscript

This will source myscript. The file need not be executable but it must be a valid shell script. The file can be in current directory or in a directory in $PATH.

. myscript

This will also source myscript. This "spelling" is the official one as defined by POSIX. Bash defined source as an alias to the dot.


Consider myscript.sh with following content:

# 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

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

Now we execute the file:

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

Check the environment again:

$ env | grep FOO
$ echo $PWD

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. The check afterwards show that the variable is not set and the directory not changed. What happened? The changes were made in a new shell. The current shell spawned a new shell to run the script. The script is running 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
PWD: /home/lesmana
PWD: /home/lesmana/somedir

Check the environment again:

$ env | grep FOO
$ echo $PWD

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

Sourcing the script does not create a new shell. All commands are run 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:

echo $$

(the special variable $$ expands to the PID of the current running shell process)

First print the PID of the current shell:

$ echo $$

Source the script:

$ source pid.sh

Execute the script, note the PID:

$ ./pid.sh

Source again:

$ source pid.sh

Execute again:

$ ./pid.sh

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.


Both sourcing and executing the script will run 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.

Use source if you want the script to change the environment in your currently running shell. use execute otherwise.

See also:


Posted 2009-12-11T15:24:17.607

Reputation: 14 930

So source is sort of like running it in a global scope, and executing creates a new local scope. Can this be extended to a function in a script? to execute a function (normally) or to "source" it? – aliteralmind – 2015-01-10T20:35:40.433

calling a shell function normally behaves much like sourcing. calling a shell function inside a subshell behaves much like executing. – lesmana – 2015-01-12T19:36:03.107

3Is there a difference between using source myscript.sh and . myscript.sh? – Holloway – 2015-03-17T09:37:12.217

3practically no difference if using bash. source is an alias to dot in bash. – lesmana – 2015-03-17T22:02:18.630

2I love it when people provide such elaborate examples so that even Linux newbies like myself can understand. Thanks! – Julius – 2017-09-23T16:00:17.997

How does one pass enviromental variables to a script that one executes? Does the new shell read from .bashrc if it's running bash? – Karl Morrison – 2018-03-08T16:02:53.320

environment variables are not passed to scripts (or any process for that matter). they are "inherited". i looked for a text that explains that clearly but found none. this was the best i found: https://www.gnu.org/software/bash/manual/html_node/Command-Execution-Environment.html perhaps this will help you in your research: https://unix.stackexchange.com/questions/130985/if-processes-inherit-the-parents-environment-why-do-we-need-export

– lesmana – 2018-03-09T15:16:42.413

thank you for your thorogh explanation! Maybe the completeness would benefit from two remarks: how to open a subshell by hand (now . is equivalent to typing, but the reader can't see what's the by-hand equivalent of execute) - and a remark on the shebang in the beginning of your script (bash seems to be the default if this line is missing?) – Ilja – 2018-12-06T08:27:31.613

@lesmana I have a bunch of "helper" bash utilities I've written accumulated over the years. What's a better idea? 1) Source a script containing functions, then invoke the functions 2) Create a directory of bash scripts, add the directory to path, and then invoke those scripts – Alexander - Reinstate Monica – 2019-07-12T19:03:29.133

I recommend leaving them as scripts. IMO more advantages. But ultimately many details and personal preference decide what is better. My rule of thumb: If the function is exclusively to customize something in bash, for exampe the prompt, then sourcing is fine. – lesmana – 2019-07-13T10:22:53.500

Is it possible for a user to run a shell script to modify the PATH variable of the current shell session (like what the system does with .bashrc)? – yildizabdullah – 2019-12-26T12:20:30.523

I don't know why but . run.shdoes exactly what I want. – yildizabdullah – 2019-12-26T12:29:52.890

2One use of sourcing is creating a rudimentary form of configuration file for your scripts. You begin by setting various variables to default values, and then source in something like myscript.conf - and that sourced script can have assignment statements that override whatever values you want. Since the sourced script doesn't begin with #/bin/bash it isn't encouraged to execute it directly. – LawrenceC – 2014-06-04T13:24:33.413


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


$ set `date`
$ ./a.sh

gives me:


Hope that helps.


Posted 2009-12-11T15:24:17.607

Reputation: 686

5although this answer is correct in every way i find it very hard to understand because it is demonstrated using another concept (setting positional parameters), which is, in my opinion, even more confusing than the difference of sourcing and executing itself. – lesmana – 2010-08-16T18:35:59.640


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.

John Weldon

Posted 2009-12-11T15:24:17.607

Reputation: 1 411


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


Posted 2009-12-11T15:24:17.607

Reputation: 61

2True, but if that's a problem, you can always run bash myscript. – Daniel Beck – 2012-02-23T07:31:07.943


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.

Arkaitz Jimenez

Posted 2009-12-11T15:24:17.607

Reputation: 173


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).


Posted 2009-12-11T15:24:17.607



source command executes the provided script (executable permission is not mandatory) in the current shell environment, while ./ executes the provided executable script in a new shell.

Also, check this answer for example: https://superuser.com/a/894748/432100

Harsh Vakharia

Posted 2009-12-11T15:24:17.607

Reputation: 401