I am confused by “one only dot – space – shell script name” (like . myshellscript) and “path to shell script” (like ./myshellscript) commands.
What for they are? I noticed the command . myshellscript executes shell script even with -rw-rw-r–. But ./myshellscript doesn’t. So I am confused.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
help source says:
source: source filename [arguments]
Execute commands from a file in the current shell.
Read and execute commands from FILENAME in the current shell. The
entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.
Exit Status:
Returns the status of the last command executed in FILENAME; fails if
FILENAME cannot be read.
source is a synonym for ., that means you can write both
. myshellscript
or
source myshellscript
What they do: source reads every line of the file (line by line) and executes it in the current shell.
But ./myshellscript executes the file in the current directory if it has the rights to do so. This could also be
/tmp/foo/bar/myshellscript
(to execute the file myshellscript which is in the directory /tmp/foo/bar) or
/usr/local/bin/myshellscript
That means, that here the dot is just the current directory. Therefore ./myshellscript executes the file called myshellscript in the current directory.
For example try
cd .
which changes to the current directory (no real change ;-)) or
ls .
which lists the content of the current directory.
And as @Alvin Wong commented: You can try this script
#!/bin/foobarNonExisting echo "This is the Shell that executes me:" echo $SHELL
with . or source to see, that it does not read the shebang. It just uses your current shell. Executing the script itself would lead to an error.
Method 2
Others have said the difference is sourcing vs executing but no one has outlined the functional differences.
The biggest functional difference is that exit, cd, and variable assignments will affect the currently running shell if you source it, but not if you execute it. To demonstrate, try the following:
$ cat test.sh #!/bin/bash mkdir -p test cd test pwd foo=bar echo script foo: $foo $ ./test.sh /Users/kevin/test script foo: bar $ echo $foo $ pwd /Users/kevin $ . test.sh /Users/kevin/test script foo: bar $ echo $foo bar $ pwd /Users/kevin/test $
Now try this:
$ cat test.sh #!/bin/bash exit $ ./test.sh $ . test.sh [Process completed]
As you can see, exit in an executed script will finish that script, but if you source a script with exit, it will exit your current shell!
Method 3
In bash, . and source functionally perform the same job — running a script inside the current shell.
./foo runs inside another shell, as your shell forks before execution.
If your script should be portable, always use .. source is a bash synonym, but it does not exist in POSIX.
Method 4
. is a synonym to the source command. Instead of forking a sub shell to execute the script it reads the script into the current shell environment. In other words ./script will execute the script in a spawned sub shell and does the processing there. Where . script reads the script into your current shell where your current shell will process the commands.
They do the similar things. With . script you are reading and ./script you are executing (by spawning a sub shell) so the appropriate permissions are required to do either.
Method 5
There are many answers explaining that . ~/bin/script.sh is equivalent to source ~/bin/script.sh. Here’s the explanation of why.
I have several clusters that I use for testing, and I use environment variables to point to them. Normally when you run a script, any variables set in it stay in the scope of that script. In example:
$ echo $MYFIELD #Nothing set $ cat test.sh export MYFIELD=foo #This would set it $ ./test.sh $ echo $MYFIELD #Didn't work because the script didn't carry it back to its parent $ . ./test.sh $ echo $MYFIELD #When run as a sourced script, this stayed in the context of my current shell foo
In this way, I can type . ~/env/cluster7 and then run any commands I want on that cluster, then type . ~/env/cluster3 to change all my environment variables to point to another one without having to manually set them.
Notice that “.” at the start of a line followed by a space is interpreted as a command. This is OK because you’d never execute the only file that can be named that way: the current directory. In any other context, though, such as without a following space or at any point later in the command line, it refers to the path, hence . ./test.sh. Since it is considered a command by bash, . test.sh also works.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0