# The Secret of the First Line in Linux Scripts: What Exactly Are `#!/usr/bin/env bash` and `#!/bin/bash`?

When writing scripts in Linux, it's common practice to start them with one of these lines:

```bash
#!/usr/bin/env bash
```

Or:

```bash
#!/bin/bash
```

At first glance, they might look like comments, but what is the true **identity** of this single line? And what exactly is the difference between the two? In this post, we'll thoroughly understand this crucial line and explore when and how to use each method.

---

## 1. Not a Comment: What is a shebang? {#sec-9f8041c620ba}

The line starting with `#!` is called a **shebang**.

```bash
#!/bin/bash
```

From the shell's perspective, starting with `#` makes it look like a "comment." However, from the **operating system (kernel)**'s perspective, it's not a comment but rather:

> "An instruction that tells where the **interpreter program** to execute this script is located."

In essence, this means:

*   `#!/bin/bash` → "Execute this file with `/bin/bash`."
*   `#!/usr/bin/env bash` → "Find the `bash` interpreter via `env` and execute this file with it."

---

## 2. How Does the Kernel Execute a Script? {#sec-33d96b8d8f01}

The execution process, simplified, goes like this:

1.  A user executes a script with execute permissions.

    ```bash
    chmod +x script.sh
    ./script.sh
    ```

2.  The kernel reads `script.sh`.
3.  It checks if the **first two characters** of the file are `#!`.
4.  If they are, it interprets the rest of the line as:

    *   "Interpreter path + arguments"
    *   And executes that program, passing the **script file path as an argument**.

For example, if `script.sh` starts with:

```bash
#!/bin/bash
```

The kernel's actual action can be roughly understood as:

```bash
/bin/bash script.sh
```

In other words, the kernel performs an action similar to what we would do by explicitly running `bash script.sh`.

> Note:
> There **must be no space** before `#!/`.
> The **first character** of the file must be `#`, and the second must be `!`.

---

## 3. Meaning and Characteristics of `#!/bin/bash` {#sec-52f9e12dce0d}

This is the most frequently seen form.

```bash
#!/bin/bash
```

### Meaning {#sec-a97a945792d4}

*   "This is a **bash script**, and `bash` is located at `/bin/bash`."
*   The kernel will always execute `/bin/bash` when running this script.

### Advantages {#sec-a01bf708579d}

*   **Clarity**: Always using `/bin/bash` makes it easy to predict which bash will be used.
*   **Performance/Simplicity**: It runs directly without involving `env`, so there's no path search process.
*   In many Linux distributions, `/bin/bash` is treated as a de facto "standard location."

### Disadvantages {#sec-89064c01f1ea}

*   **May not be portable**

    *   On some systems, bash might be located at `/usr/bin/bash`, `/usr/local/bin/bash`, or other paths.
    *   Some systems might not even have bash installed, only `/bin/sh`.
*   Specifically, in environments like **macOS, BSD variants, NixOS, or certain container setups**, the path might differ.

---

## 4. Meaning and Characteristics of `#!/usr/bin/env bash` {#sec-97cd6f02458d}

This form is increasingly common in modern scripts.

```bash
#!/usr/bin/env bash
```

The key here is `/usr/bin/env`.

*   `env` is a utility that helps with "setting/checking environment variables + searching for programs in PATH."

*   You can think of the kernel executing it like this:

    ```bash
    /usr/bin/env bash script.sh
    ```

*   `env` looks at the system's `PATH` environment variable and searches for the `bash` executable within it, then runs it.

### Advantages {#sec-9bc2075d78b3}

1.  **Portability (Works well across various environments)**

    *   Whether bash is at `/bin/bash`, `/usr/bin/bash`, or `/usr/local/bin/bash`,
    *   `env` will find it as long as it's properly registered in the `PATH`.

2.  **Uses the user's preferred bash**

    *   If a user has customized their `PATH` to prioritize a specific version of bash, that version will be used.

3.  **Same pattern used in Python and other languages**

    ```python
    #!/usr/bin/env python3
    ```

### Disadvantages {#sec-0ba7b1b3de08}

1.  **Prerequisite: `/usr/bin/env` must exist**

    *   While present on almost all modern Unix/Linux systems, it might not be in very specialized environments.

2.  **Different interpreters might be picked depending on PATH**

    *   If the `PATH` setting is misconfigured, or an unexpected bash is found first, an unintended version might execute.

3.  **Requires caution from a security perspective in some cases**

    *   In highly security-sensitive environments, some prefer **absolute paths** over `PATH`-based interpreter discovery.

---

## 5. Comparison Summary of the Two Methods {#sec-f327651f1197}

Let's summarize with a simple comparison table.

| Category                    | #!/bin/bash            | #!/usr/bin/env bash             |
| :-------------------------- | :--------------------- | :------------------------------ |
| Interpreter location method | Fixed absolute path    | Searches via `PATH`             |
| Portability (System compatibility) | Low (breaks if path differs) | High (OK if bash is in PATH)    |
| Which bash is used          | Always `/bin/bash`     | The first `bash` found in PATH  |
| Guaranteed version          | Relatively easy        | Can vary based on PATH status   |
| Security/Control            | Stronger (fixed path)  | Slightly looser (PATH dependent)|
| General Modern Trend        | Relatively older style | More commonly recommended recently |

---

## 6. When to Use Which Method? {#sec-a9bac1ab9ba2}

For the question "So, what should I use?", let's break it down by situation.

### 1) Personal / Team Development Scripts (General Development Environments) {#sec-fc5216000f29}

*   Generally, the following is recommended:

    ```bash
    #!/usr/bin/env bash
    ```

*   Reason:

    *   The bash location might differ across developer-managed servers, local environments, or CI environments.
    *   `PATH`-based execution is more flexible, and modern tools/scripts often prefer this method.

### 2) Operational Scripts Tailored for Specific Server Environments {#sec-204ac6ba64d3}

*   For example, if all servers within a company consistently have bash installed at `/bin/bash`,

*   And the server environment is quite stable, then:

    ```bash
    #!/bin/bash
    ```

*   Reason:

    *   Ensures the use of the exact same interpreter every time.
    *   Can reduce unexpected behavior caused by `PATH` modifications.

### 3) If You Need Maximum Portability? {#sec-6ef1b12d728e}

*   If you're in an environment where "bash might not even be installed," you should first consider if a bash-dependent script is appropriate.

*   If possible, write it in `sh` and use:

    ```bash
    #!/bin/sh
    ```

*   This approach will run in a much wider range of environments. However, you must avoid bash-specific syntax (like `[[ ]]`, arrays, extended string processing, etc.).

---

## 7. Practical Tips When Using `#!/usr/bin/env bash` {#sec-e5a739214684}

### 1) How to Execute Scripts {#sec-83e5cc5b64a5}

To properly utilize shebangs, instead of just doing this:

```bash
bash script.sh   # ← Executing this way largely ignores the shebang
```

It's better to use it as follows:

```bash
chmod +x script.sh   # Grant execute permission
./script.sh          # Execute directly
```

This ensures the kernel reads `#!` and uses the specified interpreter.

### 2) Checking Argument Passing {#sec-90ca3c9235bf}

For example, let's say you create `test.sh` like this:

```bash
#!/usr/bin/env bash

echo "Interpreter: $0"
echo "Arguments: $@"
```

Execution:

```bash
chmod +x test.sh
./test.sh hello world
```

Output:

```text
Interpreter: ./test.sh
Arguments: hello world
```

Here, `$0` represents "the path of the script file itself," and you just need to remember that the kernel is actually executing it like `/usr/bin/env bash test.sh hello world`.

---

## 8. Frequently Asked Questions {#sec-99b0325925f3}

### I've seen scripts written without a shebang. Is that okay? {#sec-751234a46d29}

*   That's right, it's **not always necessary**.

*   If you explicitly specify the interpreter for execution as shown below, a shebang is not needed. Even if a shebang is present, it will be ignored.

    ```bash
    bash myscript.sh
    python3 myscript.py
    ```

*   However, if you want to execute it like this, a shebang is essential:

    ```bash
    ./myscript.sh
    ./myscript.py
    ```

*   Especially for "tool-type" scripts that others might use, a **shebang is almost indispensable**.


### "I've also seen `#!/bin/env` instead of `#!/usr/bin/env`. Is that valid?" {#sec-6de89a827da4}

*   Some systems might have `/bin/env`.
*   However, `/usr/bin/env` is generally the more universal standard location.
*   Unless you have a specific reason, using `#!/usr/bin/env …` is safer.

---

## 9. Summary {#sec-971578a5a9d1}

*   `#!/usr/bin/env bash` and `#!/bin/bash` are **not comments, but directives that tell the kernel "execute this script with this interpreter."**
*   `#!/bin/bash`

    *   Always uses `/bin/bash` → **Predictable in fixed environments, but may not be portable**
*   `#!/usr/bin/env bash`

    *   Finds bash in `PATH` → **More flexible and portable, but affected by PATH status**
*   For general development/deployment environments, if you're writing scripts in a "modern style," it's recommended to **use `#!/usr/bin/env bash` as the default**.

![image of shebang in linux script](https://blog.mikihands.com/media/editor_temp/6/692ed85d-0eb6-4fd1-ab7a-22a2d189175d.png "Image illustrating shebang's working principle")