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: 
This addresses how the kernel finds and executes the command you just typed.

When you have a file in the current directory and you execute it with

```
./file

```

the kernel examines the permissions of the file, and then examines the first line of the file, and if it finds a [shebang line](http://en.wikipedia.org/wiki/Shebang_%28Unix%29), it simply uses that. A proper Bash script should have `#!/bin/bash` or possibly `#!/usr/bin/env bash` where the path to the binary can be different on different systems (maybe you have Bash in `/usr/bin/bash` or `/usr/local/bin/bash` on your system).

(If the file does not have [executable permission](http://en.wikipedia.org/wiki/Chmod) for you, you simply get an error, and the contents of the file are ignored.)

If the file is in a directory on the `PATH`, you don't need to specify its path (which in the previous case was a relative path -- `./` means "in the current directory"), and it doesn't need to be in the current directory.

```
bash

```

finds a binary named `bash` from somewhere on your `PATH` (probably somewhere like `/bin/bash`) and executes that. In the absence of a shebang line, the file is examined for a [magic marker](http://en.wikipedia.org/wiki/File_format#Magic_number), which in this case is an ELF binary magic marker, and so the routine to execute that kind of file is invoked. As a final fallback, the file is passed to the user's default shell, as described below.

Finally,

```
bash ./file

```

or

```
bash file

```

launches `bash` and gives it the `file` as its first argument. (In the latter case, `file` can be a file on your `PATH`, too.) This can have two outcomes;

* The file contains a valid Bash script, and it is executed.
* The file contains something else, but it is interpreted as Bash commands anyway.

There is also

```
sh file

```

which is correct only if the file contains `sh` commands, which is a subset of the commands allowed by `bash`. It is a fairly common error to execute Bash scripts with `sh` (whereas executing proper `sh` files with `bash` is fine, albeit somewhat wasteful, because Bash is backwards-compatible with `sh`).

Regarding `sudo`, it doesn't really make sense to allow `sudo ./script` because the user could simply create a script which contains `bash -i` to gain root privileges. Perhaps disallowing `sudo bash` is just meant as a gentle nudge to remind privileged users to not be overtly sloppy with their privileges (but if they don't understand the nudge, it's clearly not serving the intended purpose; and obviously, the security of the system will already be extremely questionable).
```
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.