Question: There are two ways of executing a bash script from a Linux CLI.

Either you do:

```
bash myscript.sh

```

or:

```
./myscript.sh

```

At first I thought both methods were identical. However I've noticed at my work that `sudo bash` is disabled by system administration (ie I need root permission to do that) while `sudo ./` is no problem.

What is the difference between launching a script through `bash myscript.sh` vs `./myscript.sh`? And is there a logical explanation for not allowing the user to execute a script through `sudo bash myscript.sh` while allowing him to do `./myscript.sh`?

Answer: 
```
bash myscript.sh

```

This runs `bash` (which must be in a directory that is part of your `PATH`) in a new process and instructs it (assuming that `bash` refers to the Bash shell) to load and execute `myscript.sh` (which must be in a directory that is part of your `PATH` or in that process' current working directory). Note that it is always `bash` that will be used to interpret the content of `myscript.sh` in this case.

```
./myscript.sh

```

This runs `./myscript.sh`. In the course of this, the file is checked for a [shebang](http://en.wikipedia.org/wiki/Shebang_%28Unix%29) line. The script is executed in a new process using the shell specified in that line, or using a default shell (as specified in the `SHELL` environment variable or `/etc/passwd`). Therefore the actual program interpreting `myscript.sh` may vary in this case.
When you use `./hello.bash` in your current shell and type enter, this happen in the system

```
strace -ff -p 4768 #PID OF MY MAIN SHELL
Process 4768 attached
read(0, ".", 1)                         = 1
write(2, ".", 1)                        = 1
read(0, "/", 1)                         = 1
write(2, "/", 1)                        = 1
read(0, "h", 1)                         = 1

write(2, "h", 1)                        = 1
read(0, "e", 1)                         = 1
write(2, "e", 1)                        = 1
read(0, "\t", 1)                        = 1

stat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/home/tux", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/home/tux/programming", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/home/tux/programming/bash", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/home/tux/programming/bash/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3

getdents(3, /* 5 entries */, 32768)     = 128 

geteuid()                               = 1000
getegid()                               = 1000
getuid()                                = 1000
getgid()                                = 1000
access("./hello.bash", X_OK)            = 0
stat("./hello.bash", {st_mode=S_IFREG|0775, st_size=32, ...}) = 0
geteuid()                               = 1000
getegid()                               = 1000
getuid()                                = 1000
getgid()                                = 1000
access("./hello.bash", R_OK)            = 0
clone(Process 4998 attached
[pid  4998] execve("./hello.bash", ["./hello.bash"], [/* 55 vars */]) = 0

```

From what i think, the shell check if file exist using stat system call and the execution permission and read permission, after that you can see a new process begin create with clone syscall and after that the script begin executed in the new process, i think everything happen in user space, the only thing the kernel does is the system call and load the proccess image in memory with the help of the linker