Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

What's the difference between executing a script like this:

./test.sh

and executing a script like this:

. test.sh?

I tried a simple, two-line script to see if I could find if there was a difference:

#!/bin/bash
ls

But both . test.sh and ./test.sh returned the same information.

Thanks.

share|improve this question
    
Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'. –  kuyan Jul 25 '12 at 6:32
1  
Just as test.sh is not the same as ./test.sh (the first invokes a PATH search), so are . test.sh and . ./test.sh different in the same way (the former invokes a PATH search). Many shells seem to implicitly include . at the end of PATH when doing a . path search, but this behavior is not standard. Thus, it is more accurate to compare test.sh vs . test.sh and ./test.sh vs . ./test.sh. –  jw013 Jul 30 '12 at 21:13
add comment

4 Answers

up vote 43 down vote accepted

./test.sh runs test.sh as a separate program. It may happen to be a bash script, if the file test.sh starts with #!/bin/bash. But it could be something else altogether.

. ./test.sh execute the code of the file test.sh inside the running instance of bash. It works as if the content file test.sh had been included textually instead of the . ./test.sh line. (Almost: there are a few details that differ, such as the value of $BASH_LINENO, and the behavior of the return builtin.)

source ./test.sh is identical to . ./test.sh in bash (in other shells, source may be slightly different or not exist altogether; . for inclusion is in the POSIX standard).

The most commonly visible difference between running a separate script with ./test.sh and including a script with the . builtin is that if the test.sh script sets some environment variables, with a separate process, only the environment of the child process is set, whereas with script inclusion, the environment of the sole shell process is set. If you add a line foo=bar in test.sh and echo $foo at the end of the calling script, you'll see the difference:

$ cat test.sh
#!/bin/sh
foo=bar
$ ./test.sh
$ echo $foo

$ . ./test.sh
$ echo $foo
bar
share|improve this answer
9  
Also adding echo $$ to the script will show the difference quite clear. The $$ variable holds the PID of the current shell. –  Herman Torjussen Jul 25 '12 at 10:15
    
Another usage scenario is using the . ./test.sh call from within another shell script to use functions that are described within test.sh. I mean, it is not just variables that you can set, you can also create new functions in this way which are then callable from bash, or some other script. . /usr/libexec/company/tools; custom_command "variable" –  Rqomey Jul 31 '12 at 8:33
add comment

Running a script the first way runs it as a child process. Sourcing (the second way), on the other way, runs the script as if you entered all its commands into the current shell - if the script sets a variable, it will remain set, if the script exits, your session will exit. See help . for documentation.

share|improve this answer
add comment

Another thing that I note is that if you have an alias like this:

# add into .bashrc_aliases
alias ls='ls -lht'

With ./test.sh you'll get a normal ls output (and a different PID than current shell):

auraham@pandora:~/iso$ ./test.sh 
dsl-4.4.10.iso  test.sh
3136 # PID

With . test.sh or . ./test.sh you'll get a more detailed output (and the same PID than current shell):

auraham@pandora:~/iso$ echo $$
2767 # shell PID

auraham@pandora:~/iso$ . test.sh 
total 50M
drwxrwxr-x  2 auraham auraham 4.0K Jul 30 15:41 .
-rwxrwxr-x  1 auraham auraham   32 Jul 30 15:41 test.sh
drwxr-xr-x 50 auraham auraham 4.0K Jul 30 15:30 ..
-rw-rw-r--  1 auraham auraham  50M Jul 28 17:24 dsl-4.4.10.iso
2767 # PID
share|improve this answer
    
You can include this in .bashrc if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi Then, put your aliases in .bash_aliases. –  auraham Aug 1 '12 at 1:17
    
Of course, but don't you still have to use the alias keyword? (Maybe that's just a mistake in you post -- on line 3?) –  Emanuel Berg Aug 1 '12 at 10:26
    
totally correct, my mistake. Thanks @EmanuelBerg –  auraham Aug 1 '12 at 18:40
add comment

The main usage to me for source (or .) is bash functions.

I have scripts with many functions and I execute all of them with my .bashrc. The functions "become" commands, which I use often.

share|improve this answer
    
I tried all three methods in .bashrc -- source, the absolute position of the script, and the name of the command (placing the script in a PATH folder) -- and all three methods worked. –  Emanuel Berg Jul 31 '12 at 0:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.