What Is Shebang Linux? Syntax & Usage

The shebang line is the first line of a script file on Linux and other Unix-like systems. It tells the operating system which interpreter to use to execute the file. You write it as #! followed by the absolute path to the interpreter, such as #!/bin/bash. This article explains what the shebang is, where the name comes from, how it works, and how to use it correctly in your own scripts.

What Exactly Is a Shebang?

The shebang is a two-character sequence, #!, placed at the very start of a text file. When you run that file directly (for example, by typing ./script.sh in a terminal), the Linux kernel reads the first two bytes. If they are #!, the kernel treats the rest of that first line as the command to run the file. The path after the shebang points to an interpreter program, and the file itself is passed to that interpreter as an argument.

For example, a file beginning with #!/usr/bin/env python3 will be executed by the Python 3 interpreter found in the user’s PATH. A file beginning with #!/bin/bash runs with the Bash shell. Without a shebang, the kernel tries to run the file as a binary executable; if it is plain text, you get an error like Exec format error.

Origin of the Word “Shebang”

The word shebang is informal slang. It is not a formal technical term found in the POSIX standard, though it is universally used by programmers. The standard documentation often calls it the hashbang, pound-bang, or hash-bang instead.

The origin of the slang is a combination of the two characters: “she” from sharp (another name for the # symbol in music) and “bang” from the exclamation mark !. The term appears to have been in use among Unix programmers since the late 1970s or early 1980s, though its exact first use is not documented. The word “shebang” itself existed earlier in English as slang for a matter or affair (as in “the whole shebang”), but that meaning is unrelated to computing.

In everyday usage, you might say: “I forgot to add the shebang to my script, so the kernel wouldn’t run it.” That sentence is correct and reflects how the word is used in practice.

How the Kernel Processes the Shebang

When you execute a file, the kernel checks the first two bytes. If they are #!, it reads the rest of the line up to the newline character. This line is then split into two parts: the interpreter path and an optional single argument. The kernel constructs a new command line consisting of the interpreter path, the optional argument, and the path to your script file.

For example, if your script starts with #!/usr/bin/python3 -O, the kernel effectively runs:

/usr/bin/python3 -O /path/to/your/script

There are two important limitations. First, the shebang line has a maximum length, typically 127 characters on Linux, though this can vary. Second, only one optional argument is supported on most systems; if you try to pass two arguments, the kernel treats everything after the interpreter path as a single argument, which usually causes an error.

Using `#!/usr/bin/env` vs. a Direct Path

There are two common ways to write a shebang for interpreters like Python or Perl:

Direct path: #!/usr/bin/python3 — This is predictable and fast, but it fails if Python is installed in a different location (for example, /usr/local/bin/python3 on some systems).
env wrapper: #!/usr/bin/env python3 — This searches the user’s PATH for python3 and runs the first match. It is more portable across systems where interpreters live in different directories, and it works well with virtual environments.

The env approach is generally recommended for portability, especially for Python and Node.js scripts. However, it is slightly slower because it spawns an extra process. For shell scripts, you almost always want a direct path like #!/bin/bash because env is unnecessary and the shell location is consistent across Linux distributions.

Common Mistakes and Pitfalls

Several errors are common when working with shebangs:

Missing shebang: The file is treated as a binary, and you get Exec format error.
Wrong line endings: If the file was edited on Windows and has a carriage return () at the end of the shebang line, the kernel tries to execute /bin/bash, which does not exist. You will see an error like bad interpreter: No such file or directory.
Spaces before the shebang: The #! must be the very first two bytes of the file. A leading space or a UTF-8 byte-order mark (BOM) will break it.
Wrong interpreter path: Typing #!/bin/sh when you need Bash-specific features will cause subtle bugs, because sh is often a different shell (like Dash on Debian/Ubuntu).
File not executable: Even with a correct shebang, you must run chmod +x script.sh to set the executable permission bit.

Shebang in Different Script Types

Here are typical shebang lines for common interpreters:

#!/bin/sh — POSIX shell script (most portable, but limited features).
#!/bin/bash — Bash shell script with advanced features like arrays and [[ ]].
#!/usr/bin/env python3 — Python 3 script.
#!/usr/bin/env node — Node.js script.
#!/usr/bin/perl — Perl script.
#!/usr/bin/awk -f — AWK program (note the -f flag is required).

For interpreters that need a flag, like awk -f or python3 -O, you can include that single flag in the shebang. Remember that only one argument is reliably supported, so you cannot write #!/usr/bin/python3 -O -E and expect both flags to work on all systems.

Security Considerations

The shebang itself is not a security risk, but it has one important implication: when you run a script directly, the interpreter runs with your user privileges, not with any special permissions. If a script has the setuid bit set (the s permission in ls -l), most Linux kernels ignore it for scripts with a shebang for security reasons. This means you cannot create a setuid script that runs as root simply by adding a shebang. If you need elevated privileges, use sudo or a compiled helper program instead.

Another minor risk is the env shebang: if an attacker can place a fake python3 earlier in your PATH, your script will run that instead. This is only a concern in untrusted directories, so always check your PATH and avoid running scripts from directories you do not control.

Frequently Asked Questions

Is the shebang required for all scripts?

No. If you always run the script by explicitly calling the interpreter (for example, python3 script.py), the shebang is ignored. It is only needed when you want to run the file directly as an executable.

Can the shebang point to a script instead of a binary?

Yes, but it is unusual. You can point to another script that has its own shebang, and the kernel will chain them. However, this adds complexity and is rarely needed.

What happens if the interpreter path is wrong?

The kernel returns an error like bad interpreter: No such file or directory. The script does not run. Double-check the path with which python3 or command -v bash.

Does the shebang work on Windows?

Not natively. Windows does not use shebangs. However, tools like Git Bash, Cygwin, or the Windows Subsystem for Linux (WSL) do support them because they emulate a Unix environment.

What is the difference between `#!/bin/sh` and `#!/bin/bash`?

/bin/sh is the POSIX shell, which on many Linux systems is actually Dash, a smaller and faster shell. /bin/bash is the Bourne Again Shell with many extra features. If your script uses Bash-specific syntax like arrays or [[ ]], you must use #!/bin/bash.

Can I use a shebang with spaces in the interpreter path?

No. The kernel treats the first token after #! as the path, and spaces are not handled. If your interpreter is in a path with spaces, create a symlink without spaces or use the env wrapper.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →