What is the difference between sourcing ('.' or 'source') and executing a file in bash?
Clash Royale CLAN TAG#URR8PPP
up vote
62
down vote
favorite
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.
bash shell
add a comment |Â
up vote
62
down vote
favorite
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.
bash shell
Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
â Natan
Jul 25 '12 at 6:32
3
Just astest.sh
is not the same as./test.sh
(the first invokes aPATH
search), so are. test.sh
and. ./test.sh
different in the same way (the former invokes aPATH
search). Many shells seem to implicitly include.
at the end ofPATH
when doing a.
path search, but this behavior is not standard. Thus, it is more accurate to comparetest.sh
vs. test.sh
and./test.sh
vs. ./test.sh
.
â jw013
Jul 30 '12 at 21:13
add a comment |Â
up vote
62
down vote
favorite
up vote
62
down vote
favorite
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.
bash shell
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.
bash shell
edited Sep 14 '16 at 9:32
terdonâ¦
122k28230401
122k28230401
asked Jul 25 '12 at 1:11
Natan
415159
415159
Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
â Natan
Jul 25 '12 at 6:32
3
Just astest.sh
is not the same as./test.sh
(the first invokes aPATH
search), so are. test.sh
and. ./test.sh
different in the same way (the former invokes aPATH
search). Many shells seem to implicitly include.
at the end ofPATH
when doing a.
path search, but this behavior is not standard. Thus, it is more accurate to comparetest.sh
vs. test.sh
and./test.sh
vs. ./test.sh
.
â jw013
Jul 30 '12 at 21:13
add a comment |Â
Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
â Natan
Jul 25 '12 at 6:32
3
Just astest.sh
is not the same as./test.sh
(the first invokes aPATH
search), so are. test.sh
and. ./test.sh
different in the same way (the former invokes aPATH
search). Many shells seem to implicitly include.
at the end ofPATH
when doing a.
path search, but this behavior is not standard. Thus, it is more accurate to comparetest.sh
vs. test.sh
and./test.sh
vs. ./test.sh
.
â jw013
Jul 30 '12 at 21:13
Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
â Natan
Jul 25 '12 at 6:32
Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
â Natan
Jul 25 '12 at 6:32
3
3
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
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 a comment |Â
4 Answers
4
active
oldest
votes
up vote
69
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
executes 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
17
Also addingecho $$
to the script will show the difference quite clear. The$$
variable holds the PID of the current shell.
â user13742
Jul 25 '12 at 10:15
1
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 a comment |Â
up vote
9
down vote
Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, 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.
add a comment |Â
up vote
3
down vote
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
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 thealias
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 a comment |Â
up vote
-1
down vote
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.
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 a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
69
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
executes 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
17
Also addingecho $$
to the script will show the difference quite clear. The$$
variable holds the PID of the current shell.
â user13742
Jul 25 '12 at 10:15
1
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 a comment |Â
up vote
69
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
executes 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
17
Also addingecho $$
to the script will show the difference quite clear. The$$
variable holds the PID of the current shell.
â user13742
Jul 25 '12 at 10:15
1
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 a comment |Â
up vote
69
down vote
accepted
up vote
69
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
executes 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
./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
executes 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
edited Jan 18 '17 at 18:29
Jeff Schaller
31.2k846105
31.2k846105
answered Jul 25 '12 at 1:27
Gilles
505k1199991527
505k1199991527
17
Also addingecho $$
to the script will show the difference quite clear. The$$
variable holds the PID of the current shell.
â user13742
Jul 25 '12 at 10:15
1
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 a comment |Â
17
Also addingecho $$
to the script will show the difference quite clear. The$$
variable holds the PID of the current shell.
â user13742
Jul 25 '12 at 10:15
1
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
17
17
Also adding
echo $$
to the script will show the difference quite clear. The $$
variable holds the PID of the current shell.â user13742
Jul 25 '12 at 10:15
Also adding
echo $$
to the script will show the difference quite clear. The $$
variable holds the PID of the current shell.â user13742
Jul 25 '12 at 10:15
1
1
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
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 a comment |Â
up vote
9
down vote
Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, 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.
add a comment |Â
up vote
9
down vote
Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, 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.
add a comment |Â
up vote
9
down vote
up vote
9
down vote
Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, 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.
Running a script the first way runs it as a child process. Sourcing (the second way), on the other hand, 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.
edited Mar 9 at 12:45
answered Jul 25 '12 at 1:17
choroba
24.3k33967
24.3k33967
add a comment |Â
add a comment |Â
up vote
3
down vote
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
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 thealias
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 a comment |Â
up vote
3
down vote
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
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 thealias
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 a comment |Â
up vote
3
down vote
up vote
3
down vote
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
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
edited Aug 1 '12 at 18:39
answered Jul 30 '12 at 20:44
auraham
1313
1313
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 thealias
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 a comment |Â
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 thealias
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
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
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
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
totally correct, my mistake. Thanks @EmanuelBerg
â auraham
Aug 1 '12 at 18:40
add a comment |Â
up vote
-1
down vote
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.
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 a comment |Â
up vote
-1
down vote
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.
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 a comment |Â
up vote
-1
down vote
up vote
-1
down vote
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.
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.
edited Nov 29 '12 at 8:40
Mat
37.6k7114123
37.6k7114123
answered Jul 25 '12 at 2:29
Willian Paixao
1,42711029
1,42711029
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 a comment |Â
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
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
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 a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f43882%2fwhat-is-the-difference-between-sourcing-or-source-and-executing-a-file-i%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Apologies if this is a duplicate - upon further investigation, I found some pages with relevant information by searching for 'bash dot' instead of 'bash .'.
â Natan
Jul 25 '12 at 6:32
3
Just as
test.sh
is not the same as./test.sh
(the first invokes aPATH
search), so are. test.sh
and. ./test.sh
different in the same way (the former invokes aPATH
search). Many shells seem to implicitly include.
at the end ofPATH
when doing a.
path search, but this behavior is not standard. Thus, it is more accurate to comparetest.sh
vs. test.sh
and./test.sh
vs. ./test.sh
.â jw013
Jul 30 '12 at 21:13