Shebang: the first line of a script

What it is

When the kernel gets a request to execute a file that has the +x bit, it reads the first two bytes. If they are #!, called the shebang (or hashbang), the rest of the line is read as a path to the interpreter.

#!/usr/bin/env bash

echo hello

When you run ./script.sh, the kernel sees #! → starts /usr/bin/env bash ./script.sh → env finds bash in $PATH → bash interprets the script.

Without #!, the behavior depends on who runs it:

• From a bash shell, bash runs it as a bash script
• From dash/zsh/fish, it may run under the rules of that shell
• Through exec() with no shell, the kernel refuses with ENOEXEC

So always write a shebang.

/bin/bash vs /usr/bin/env bash

Two forms you see often:

#!/bin/bash             # hardcoded path

#!/usr/bin/env bash     # look up bash through PATH

Prefer the second one. Here is why:

The exception is #!/bin/sh. POSIX guarantees that a POSIX shell is always at /bin/sh. If your script is genuinely POSIX-compatible, write /bin/sh and save yourself the trouble.

Arguments to the interpreter

A shebang can pass one argument (a Linux limit):

#!/usr/bin/env -S bash -euo pipefail

With env -S (needs coreutils 8.30+) you can wedge strict mode straight into the shebang. The alternative is set -euo pipefail as the first line of the script.

Not only bash

A shebang works with any interpreter:

#!/usr/bin/env python3

print("hello from python")

#!/usr/bin/env ruby

puts "hi"

#!/usr/bin/env node

console.log('hi')

The /usr/bin/env <interpreter> idiom is universal. It works for all of them.

Common mistakes

• CRLF (Windows line endings): the kernel sees #!/usr/bin/env bash\r and tries to find an interpreter called bash\r. The error is bad interpreter: No such file or directory. Fix: dos2unix file.sh.
• No +x bit: run chmod +x file.sh.
• No full path: #!bash does not work, you need an absolute path.
• Shebang not on the FIRST line: the kernel looks only at the first two bytes, so a blank line before the shebang breaks the magic.