Bdtyk

From running help . or help source

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.

From my point of view, it seems like the dot command (or the source command) is simply running a shell script in the current shell context (instead of spawning another shell).

Question: why doesn't . (or source) requires the file to be executable like when you run a normal script?

Lets say I have a shell script (my-script.sh)starting with:

#!/bin/sh

If the script has execute permissions set then I can run the script with:

./my-script.sh

In this case you are ultimately asking the kernel to run my-script.sh as a program, and the kernel (program loader) will check permissions first, and then use /bin/sh ./my-script.sh to actually execute your script.

But the shell (/bin/sh) does not care about execute permissions and doesn't check them. So if you call this ...

/bin/sh ./my-script.sh

... The kernel is never asked to run my-script.sh as a program. The kernel (program loader) is only asked to run /bin/sh. So the execute permissions will never me checked. That is, you don't need execute permission to run a script like this.

To answer your question:

The difference between you calling ./my-script.sh and . ./my-script.sh inside another script is exactly the same. In the first, you are asking the kernel to run it as a program, in the second, you are asking your current shell to read commands from the script and the shell doesn't need (or care about) execute permissions to do this.

Further reading:

Running scripts as programs is surprising behaviour when you think about it. They are not written in machine code. I would read up on why this works; start with reading up on the shebang (#!) https://en.wikipedia.org/wiki/Shebang_(Unix)

Running scripts with the dot notation is necessary to share variables. All other mechanisms for running start a new shell "context", meaning that any variables set in the called script will not be passed back to the calling script. Bash documentation is a little lite, but it's here: https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html

When you say source script.sh or . script.sh you are never executing the script. What you are running is a shell command source which does something. This "something" includes reading from script.sh and executing what-has-been-read. Your script needs to be readable for this. No need for executability.

The behaviour is similar to running bash non-executable-script.sh or python non-executable-script.py etc.