Calling a script with ./bla.sh vs. . bla.sh

./bla.sh

Here, the command is ./bla.sh. This makes the shell look for an executable named bla.sh in the current directory, then ask the kernel to run it as a normal program, in a separate process from the shell. (It doesn't matter if bla.sh is a bash script, a perl or python one, or a compiled binary.)

. bla.sh

Here, the command is . (aka source), a built-in command of your shell. It makes the shell look for a file named bla.sh in the system path ($PATH) and interpret the contents as if they were typed by you; all this is done in the same process as the shell itself (and therefore can affect the shell's internal state).

This of course only works when bla.sh contains commands for the bash shell (if that's the one you are currently using), it won't work for perl scripts or anything else.

(This is explained in help . and help source too.)

As . and ./ are completely different things (a command vs part of a path), they can be combined, of course – using . ./bla.sh would "source" a file bla.sh in the current directory.

Usually it is best to use the ./bla.sh method. Only ~/.bashrc, ~/.profile and such files are usually sourced, because they are supposed to modify the current environment.

./<cmd> will execute the <cmd> program that resides in the current directory in a new (forked) process. It has to be executable. And also readable it starts with #!.

. <cmd> will make your current shell execute the shell script <cmd> that resides in your $PATH or the current directory in the current shell process. It has to be readable. It is an alias for the shell command source.

./cmd uses explicit path (./ - current dir) to executable. And it is not necessary that it starts with #!.

. cmd - (aka source) - bash builtin command. One visible difference of executing through source is that it can set/modify environment variable of current shell.