Shebang (Unix)

A "shebang" or "hashbang" character sequence

In computing, a shebang (also called a sha-bang, hashbang, pound-bang, hash-exclam, or hash-pling) is the character sequence consisting of the characters number sign and exclamation point (#!), when it occurs as the first two characters on the first line of a text file. In this case, the program loader in Unix-like operating systems parses the rest of the first line as an interpreter directive and invokes the program specified after the character sequence with any command line options specified as parameters. The name of the file being executed is passed as the final argument.

For example, a file starting with the line:

#!/bin/sh

invokes the Bourne shell or a compatible shell. This is the standard starting line of a shell script.

The contents of the shebang line will be automatically ignored by the interpreter, because the # character is a comment marker in many scripting languages. Some language interpreters that do not use the hash mark to begin comments, such as Scheme, still may ignore the shebang line.

The shebang or hashbang fragment identifiers are the one starting with exclamation mark (so that the combination ...url#fragment_id... in fact contains a shebang). They were suggested to be used in Ajax applications for stateful AJAX pages. Google Webmaster Central specifies that fragment identifiers starting with an exclamation mark (...url#!state...) are indexed specially by the Googlebot.

Syntax

The syntax of feature consists of the character sequence #!, i.e. the number sign and an exclamation point character. This initiating character sequence may be followed by whitespace, then followed by the (absolute) path to the interpreter program that will provide the interpretation. The shebang is looked for and used when a script is invoked directly (as with a regular executable), and largely to the end of making scripts look and act like regular executables, to the operating system and to the user.

Etymology and name history

The name shebang comes from an inexact contraction of SHArp bang or haSH bang, referring to the two typical Unix names of the two characters. Unix jargon uses sharp or hash (and sometimes, even, mesh) to refer to the number sign character and bang to refer to the exclamation point, hence shebang. Another theory on sh in shebang's name is from default shell sh, usually invoked with shebang.

The initial two characters, "#!" of the interpreter directive have a range of jargon terms. One, "shebang", is representative (with an American bias) but far from universal. An executable file starting with an interpreter directive is simply called a script, often prefaced with the name or general classification of the intended interpreter.

When asked about what he would call his feature (i.e. "What do you personally call that first line"), Dennis Ritchie answered:

From: "Ritchie, Dennis M (Dennis)** CTR **" <dmr@[redacted]>
To: <[redacted]@talisman.org>
Date: Thu, 19 Nov 2009 18:37:37 -0600
Subject: RE: What do -you- call your #!<something> line?

 I can't recall that we ever gave it a proper name.
It was pretty late that it went in--I think that I
got the idea from someone at one of the UCB conferences
on Berkeley Unix; I may have been one of the first to
actually install it, but it was an idea that I got
from elsewhere.

As for the name: probably something descriptive like
"hash-bang" though this has a specifically British flavor, but
in any event I don't recall particularly using a pet name
for the construction.

   Regards,
   Dennis

History

The shebang was introduced by Dennis Ritchie between Edition 7 and 8 at Bell Laboratories. It was also added to the BSD releases from Berkeley's Computer Science Research (present at 2.8BSD and activated by default by 4.2BSD). As AT&T Bell Laboratories Edition 8 Unix, and later editions, were not released to the public, the first widely known appearance of this feature was on BSD.

The lack of an interpreter directive, but support for shell scripts, is apparent in the documentation from Version 7 Unix in 1979, which describes instead a facility of the Bourne shell where files with execute permission would be handled specially by the shell, which would (sometimes depending on initial characters in the script, such as ":" or "#") spawn a subshell which would interpret and run the commands contained in the file. In this model, scripts would only behave as other commands if called from within a Bourne shell. An attempt to directly execute such a file via the operating system's own exec() system trap would fail, preventing scripts from behaving uniformly as normal system commands.

In later versions of Unix-like systems, this inconsistency was removed. Dennis Ritchie introduced kernel support for interpreter directives in January 1980, for Version 8 Unix, with the following description:

From uucp Thu Jan 10 01:37:58 1980
>From dmr Thu Jan 10 04:25:49 1980 remote from research
The system has been changed so that if a file being executed
begins with the magic characters #! , the rest of the line is understood
to be the name of an interpreter for the executed file.
Previously (and in fact still) the shell did much of this job;
it automatically executed itself on a text file with executable mode
when the text file's name was typed as a command.
Putting the facility into the system gives the following
benefits.

1) It makes shell scripts more like real executable files,
because they can be the subject of 'exec.'

2) If you do a 'ps' while such a command is running, its real
name appears instead of 'sh'.
Likewise, accounting is done on the basis of the real name.

3) Shell scripts can be set-user-ID.

4) It is simpler to have alternate shells available;
e.g. if you like the Berkeley csh there is no question about
which shell is to interpret a file.

5) It will allow other interpreters to fit in more smoothly.

To take advantage of this wonderful opportunity,
put

        #! /bin/sh

at the left margin of the first line of your shell scripts.
Blanks after ! are OK.  Use a complete pathname (no search is done).
At the moment the whole line is restricted to 16 characters but
this limit will be raised.

Kernel support for interpreter directives spread to other versions of Unix, and one modern implementation can be seen in the Linux kernel source in fs/binfmt_script.c.

This mechanism allows scripts to be used in virtually any context normal compiled programs can be, including as full system programs, and even as interpreters of other scripts. As a caveat, though, some early versions of kernel support limited the length of the interpreter directive to roughly 32 characters (just 16 in its first implementation), would fail to split the interpreter name from any parameters in the directive, or had other quirks. Additionally, some modern systems allow the entire mechanism to be constrained or disabled for security purposes (for example, set-user-id support has been disabled for scripts on many systems).

Note that, even in systems with full kernel support for the #! magic number, some scripts lacking interpreter directives (although usually still requiring execute permission) are still runnable by virtue of the legacy script handling of the Bourne shell, still present in many of its modern descendants.

Examples

Some typical shebang lines:

• #!/bin/sh — Execute the file using sh, the Bourne shell, or a compatible shell
• #!/bin/csh — Execute the file using csh, the C shell, or a compatible shell
• #!/usr/bin/perl -T — Execute using Perl with the option for taint checks
• #!/usr/bin/ruby — Execute using Ruby
• #!/usr/bin/python -O — Execute using Python with optimizations to code
• #!/usr/bin/php — Execute the file using the PHP command line interpreter

On many systems, /bin/sh is a symbolic or hard link to bash. When invoked in this manner, many features of bash are disabled, to comply with POSIX.

Shebang lines may include specific options that are passed to the interpreter (see the Perl example above). However, implementations vary in the parsing behavior of options.

Purpose

Interpreter directives allow scripts and data files to be used as system commands, hiding the details of their implementation from users and other programs, by removing the need to prefix scripts with their interpreter on the command line.

Hence, assuming a Bourne shell script in /usr/local/bin/foo with a first line of

#!/bin/sh -x

...which is run from the command line with the following (where "$" is just one possible prompt):

$ foo bar

...the result would be actual command execution equivalent (except for argv[0] being set to the filename) to:

$ /bin/sh -x /usr/local/bin/foo bar

Since sh reads commands from a filename provided on its command line (instead of from the user, as it would normally), the end result is that all the shell commands in /usr/local/bin/foo are run automatically, with bar provided as a parameter, $1, to those commands to use as they see fit.

Since the initial number sign is also the character introducing comments in the Bourne shell and many other interpreters, that interpreter directive itself is considered by the interpreter to be merely a comment, and skipped. However, it is up to the interpreter to ignore the shebang line; thus a script consisting of the following two lines:

#!/bin/cat
Hello world!

will echo both lines to standard output.

Portability

Shebangs must specify absolute paths to system executables; this can cause problems on systems that have a non-standard file system layout. Even when systems have fairly standard paths, it is quite possible for variants of the same operating system to have different locations for the desired interpreter. Python, for example, might be in /usr/bin/python, /usr/local/bin/python, or even something like /home/username/bin/python if being tested by a user.

Because of this it is common to need to edit the shebang line after copying a script from one computer to another because the path that was coded into the script may not apply on a new machine, depending on the consistency in past convention of placement of the interpreter. For this and other reasons, POSIX does not standardize the feature.

Often, the program /usr/bin/env can be used to circumvent this limitation by introducing a level of indirection. #! is followed by /usr/bin/env, followed by the desired command without full path, as in this example:

#!/usr/bin/env sh

This mostly works because the path /usr/bin/env is commonly used for the utility, and env invokes the first sh found in the user's $PATH, typically /bin/sh, if the user's path is correctly configured.

This approach may introduce vulnerabilities that expose information or gain unauthorized root access and does not grant complete portability. There are still some portability issues with OpenServer 5.0.6 and Unicos 9.0.2 which have only /bin/env and no /usr/bin/env.

Another portability problem is the interpretation of the command arguments. Some systems, including Linux, do not split up the arguments; for example, when running the script with the first line like,

#!/usr/bin/env python -c

That is, python -c will be passed as one argument to /usr/bin/env, rather than two arguments. Cygwin also behaves this way. Some other systems handle the arguments differently.

Another common problem is scripts containing a carriage return character immediately after the shebang, perhaps as a result of being edited on a system that uses DOS line breaks, such as Microsoft Windows. Some systems interpret the carriage return character as part of the interpreter command, resulting in an error message.

POSIX requires that sh is a shell capable of a syntax similar to the Bourne shell, although it does not require it to be located at /bin/sh; for example, some systems such as Solaris have the POSIX-compatible shell at /usr/xpg4/bin/sh. In many Linux systems and recent releases of Mac OS X, /bin/sh is a hard or symbolic link to /bin/bash, the Bourne Again shell.

Using syntax specific to bash while maintaining a shebang pointing to the Bourne shell is not portable.

Magic number

The shebang is actually a human-readable instance of a magic number in the executable file, the magic byte string being 0x23 0x21, the two-character encoding in ASCII. (Executable files that do not require an interpreter program start with other magic combinations. See File format for more details of magic numbers.)

Nonetheless, interpreted text files using the shebang are still text files, not binary files; a text editor that introduces superfluous leading bytes will break the constructions as the file would not start with 0x23 0x21. In particular, UTF-8—the standard character encoding for text files on many Unix-like systems—is ASCII-compatible, assigning all characters in the ASCII character set to the same one-byte codes; but UTF-8 files on Windows usually begin with a three-byte byte order mark (0xEF 0xBB 0xBF). These bytes change the magic number and thus the interpreter will not be run (unless this other magic number is also recognized). For this and other reasons, use of the byte order mark is strongly recommended against on POSIX (Unix-like) systems. A byte order mark is unneeded for UTF-8 (as opposed to UTF-16) since UTF-8 can reliably be recognised as such by a simple algorithm.

There have been rumors that some old versions of UNIX look for the normal shebang followed by a space and a slash ("#! /"), but this appears to be untrue.

On Unix-like operating systems, new image files are started by the "exec" family functions. This is where the operating system will detect that an image file is either a script or an executable binary. The presence of the shebang will result in the execution of the specified (usually script language) executable. This is described on the Solaris and Linux man page "execve".

Security issues

On some systems, scripts can be marked with the setuid attribute, set-user-ID, a Unix feature which means that a program is executed with the access rights of the program file's owner instead of the rights of the user running it. Although this mechanism may be safe for compiled code, the extra step introduced by the interpreter directive provides a extra window of opportunity of attack along the following lines:

1. An attacker makes a symbolic link in, say, /tmp/sneaky to a system shell script with setuid enabled, say /usr/bin/admintool (a hypothetical example).
2. The attacker then runs /tmp/sneaky, but pauses its execution immediately
3. If the new process had already gotten as far as opening sneaky, stop and start over, otherwise:
4. The new process has already set its user ID to the owner of /usr/bin/admintool, so it's probably now running as root with full system rights (if not, start over)
5. The attacker now removes the symbolic link pointing to /usr/bin/admintool
6. The attacker creates a new script at /tmp/sneaky but with his own illicit commands therein
7. The attacker now resumes the paused process, and the shell then opens sneaky and executes the illicit command file with root access rights.

This problem has been corrected on some modern systems, namely those supporting the /dev/fd filesystem can support the change, by opening the script first, producing a file descriptor which is safe from attack, then invoking the interpreter with that safe file descriptor as input. However, the discovery of the problem led many system administrators and developers to the conclusion that scripts couldn't be made secure, a case made more compelling by issues with the shell's internal field separator (also since corrected on modern systems); as a result, setuid functionality is often made unavailable to scripts.

As a result of these issues, setuid scripts are unsafe on older Unix-like systems, which comprise the majority of such installations. Appropriate research into the security implications of setuid scripts is therefore necessary before permitting their use. The sudo command is a widely-used alternative for providing similar functionality.

Strengths

When compared to the use of global association lists between command name extensions and the interpreting applications, the interpreter directive method allows users to use interpreters not known at a global system level, and without administrator rights. It also allows specific selection of interpreter, without overloading the filename extension namespace, and allows the implementation language of a script to be changed without changing its invocation syntax by other programs.

See also

• Crunchbang GNU/Linux distribution, commonly referred to as "#!".
• interpreter directive
• binfmt_misc
• File association
• Special Characters

External links

• Details about the shebang mechanism on various Unix flavours
• #! - the Unix truth as far as I know it (a more generic approach)
• FOLDOC shebang article