Should I use a Shebang with Bash scripts?

Question

I am using Bash

$ echo $SHELL
/bin/bash

and starting about a year ago I stopped using Shebangs with my Bash scripts. Can I benefit from using #!/bin/sh or #!/bin/bash?

Update: In certain situations a file is only treated as a script with the Shebang, example

$ cat foo.sh
ls

$ cat bar.sh
#!/bin/sh
ls

$ file foo.sh bar.sh
foo.sh: ASCII text
bar.sh: POSIX shell script, ASCII text executable

Solution 1

On UNIX-like systems, you should always start scripts with a shebang line. The system call execve (which is responsible for starting programs) relies on an executable having either an executable header or a shebang line.

From FreeBSD's execve manual page:

 The execve() system call transforms the calling process into a new
 process.  The new process is constructed from an ordinary file, whose
 name is pointed to by path, called the new process file.
 [...]

 This file is
 either an executable object file, or a file of data for an interpreter.

 [...]

 An interpreter file begins with a line of the form:

       #! interpreter [arg]

 When an interpreter file is execve'd, the system actually execve's the
 specified interpreter.  If the optional arg is specified, it becomes the
 first argument to the interpreter, and the name of the originally
 execve'd file becomes the second argument

Similarly from the Linux manual page:

execve() executes the program pointed to by filename. filename must be either a binary executable, or a script starting with a line of the form:

#! interpreter [optional-arg]

In fact, if a file doesn't have the right "magic number" in it's header, (like an ELF header or #!), execve will fail with the ENOEXEC error (again from FreeBSD's execve manpage):

[ENOEXEC] The new process file has the appropriate access permission, but has an invalid magic number in its header.

---

If the file has executable permissions, but no shebang line but does seem to be a text file, the behaviour depends on the shell that you're running in.

Most shells seem to start a new instance of themselves and feed it the file, see below.

Since there is no guarantee that the script was actually written for that shell, this can work or fail spectacularly.

From tcsh(1):

   On  systems which do not understand the `#!' script interpreter conven‐
   tion the shell may be compiled to emulate it;  see  the  version  shell
   variable.  If so, the shell checks the first line of the file to see if
   it is of the form `#!interpreter arg ...'.  If it is, the shell  starts
   interpreter  with  the  given args and feeds the file to it on standard
   input.

From FreeBSD's sh(1):

If the program is not a normal executable file (i.e., if it
     does not begin with the “magic number” whose ASCII representation is
     “#!”, resulting in an ENOEXEC return value from execve(2)) but appears to
     be a text file, the shell will run a new instance of sh to interpret it.

From bash(1):

   If this execution fails because the file is not in  executable  format,
   and  the file is not a directory, it is assumed to be a shell script, a
   file containing shell commands.  A subshell is spawned to  execute  it.

---

You cannot always depend on the location of a non-standard program like bash. I've seen bash in /usr/bin, /usr/local/bin, /opt/fsf/bin and /opt/gnu/bin to name a few.

So it is generally a good idea to use env;

#!/usr/bin/env bash

If you want your script to be portable, use sh instead of bash.

#!/bin/sh

While standards like POSIX do not guarantee the absolute paths of standard utilities, most UNIX-like systems seem to have sh in /bin and env in /usr/bin.

Solution 2

Scripts should always begin with a shebang line. If a script doesn't start with this, then it may be executed by the current shell. But that means that if someone who uses your script is running a different shell than you do, the script may behave differently. Also, it means the script can't be run directly from a program (e.g. the C exec() system call, or find -exec), it has to be run from a shell.

Solution 3

• If you write bash scripts, i.e. non portable scripts containing bashisms, you should keep using the #!/bin/bash shebang just to be sure the correct interpreter is used. You should not replace the shebang by #!/bin/sh as bash will run in POSIX mode so some of your scripts might behave differently.

• If you write portable scripts, i.e. scripts only using POSIX utilities and their supported options, you might keep using #!/bin/sh on your system (i.e. one where /bin/sh is a POSIX shell).

• It you write stricly conforming POSIX scripts to be distributed in various platforms and you are sure they will only be launched from a POSIX conforming system, you might and probably should remove the shebang as stated in the POSIX standard:

As it stands, a strictly conforming application must not use "#!" as the first two characters of the file.

The rationale is the POSIX standard doesn't mandate /bin/sh to be the POSIX compliant shell so there is no portable way to specify its path in a shebang. In this third case, to be able to use the 'find -exec' syntax on systems unable to run a shebangless still executable script, you can simply specify the interpreter in the find command itself, eg:

find /tmp -name "*.foo" -exec sh -c 'myscript "$@"' sh {} + 

Here, as sh is specified without a path, the POSIX shell will be run.

Solution 4

You might be interested in an early description by Dennis M Ritchie (dmr) who invented the #! :

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.

Hope this helps

Solution 5

The header is useful since it specifies which shell to use when running the script. For example, #!/bin/zsh would change the shell to zsh instead of bash, where you can use different commands.

For example, this page specifies the following:

Using #!/bin/sh, the default Bourne shell in most commercial variants of UNIX, makes the script portable to non-Linux machines, though you sacrifice Bash-specific features ...

View more solutions

Comments

[chepner]

Absent a shebang, most(?) OSes will try to execute a script using the system shell.

[Barmar]

I guess it's changed over time and between OSes.

[Etan Reisner]

"the system shell" is the dangerous part of @chepner's comment and the exact reason why you should use one, which is the OP's question.

[Keith Thompson]

There are arguments for and against the #!/usr/bin/env hack. See this question and my answer.

[Keith Thompson]

Without a shebang, scripts will be executed by /bin/sh, which could be any of several different Bourne-like shells. Depending on the system, it might be a symlink to dash, bash, or ksh, for example.

[Keith Thompson]

Actually, I'm not sure that they're guaranteed to be executed by /bin/sh. The #! method is not standardized by POSIX (to my surprise).

[jlliagre]

Without a shebang, the script will be executed by the POSIX shell (either directly or through find -exec) when you are in a POSIX environment running in a POSIX platform. The POSIX shell doesn't need and is not guaranteed to be /bin/sh. Specifying this PATH breaks portability in at least one well known and still commonly used commercial Unix platform so shouldn't be hardcoded by a shebang.

[Barmar]

As I understand it, POSIX doesn't even specify that #! causes it to run an interpreter at all. Everything about shebang is a de facto standard, not part of the official specification.

[Barmar]

I think the line length restriction was also raised a while back. However, I believe most implementations limit it to one argument in the shebang line.

[jrjc]

I should have state more clearly that it was the description from 1980 (despite the link). I edit for that. Note that this answer was aimed at providing some historical perspectives about what was #! invented for.

[Roland Smith]

If the script without a shebang line is started from a shell, most shells start a copy of themselves and feed it the file. See the manpage references in my answer below.

[jlliagre]

"most" != "all". You are ruling out one of the most deployed commercial Unix by assuming /bin/sh is a POSIX compliant shell.

[jrjc]

@StevenPenny Unfortunately I don't have other information than what can be found in the other answers.

[Barmar]

@RolandSmith That's what I wrote in my second sentence: it may be executed by the current shell.

[Roland Smith]

Having a /bin/sh is pretty common. I'm not assuming sh is POSIX compliant.

[jlliagre]

This somewhat contradict "If you want your script to be portable". The script will indeed start whatever the platform as /bin/sh is there, but the script might fail or behave differently at least on Solaris 10 and olders, as the SVR4 Bourne shell is lacking some features most script developers expects will work.

[Roland Smith]

My remark was in the context that these days common assumptions are that UNIX means GNU/Linux and a shell means bash.

[jlliagre]

@StevenPenny In a posix conforming environment, the first sh tells find to run the POSIX shell as it is guaranteed to be the first one found in the PATH. The second sh is setting $0, it could be almost anything but sh makes sense for a shell. {} + is filling the potential remaining arguments ($1, $2, ...) that will be passed to the myscript command.

[M Imam Pratama]

It's worth noting that shebang is only required for executable scripts.