40

I was writing a simple shell script and found out that my shell script doesn't require shebang line

#!/bin/sh

If I give execute permissions to my script and execute using ./myscript.sh. It runs fine.

I am using bash shell and /bin/sh is actually pointing to bash.

lrwxrwxrwx 1 root root /bin/sh -> bash

I know that shebang line is used to tell shell which interpreter to use for your rest of the script.

If I miss shebang line in perl, give execute permissions and run ./myscript.pl, it doesn't work.

What's actually happening here? If I use ./, When is shebang line actually needed?

3 Answers3

36

The parent shell, where you entered ./myscript.sh, first tried to execve it, which is where the shebang line would take effect if present. When this works, the parent is unaware of the difference between scripts and ELFs because the kernel takes care of it.

The execve failed, so an ancient unix compatibility feature, predating the existence of shebang lines, was activated. It guessed that a file which has execute permission but is not recognized as a valid executable file by the kernel must be a shell script.

Usually the parent shell guesses that the script is written for the same shell (minimal Bourne-like shells run the script with /bin/sh, bash runs it as a bash subprocess), csh does some more complicated guessing based on the first character because it predates shebang too and it needed to coexist with Bourne shell).

You need a shebang line when you know these guesses will be wrong (for example with the shebang is #!/usr/bin/perl), or when you don't trust the guessing to work consistently, or when the script needs to be runnable by a parent process that is not a shell itself.

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
Alan Curry
  • 14,255
  • 3
  • 32
  • 33
  • 3
    More information can be found in the answer to *Why do some scripts start with #! ... ?* question at http://www.faqs.org/faqs/unix-faq/faq/part3/section-16.html – Piotr Dobrogost Oct 08 '14 at 21:42
  • in bash, running a script containg 'history' command WITHOUT shebang show the current history, while WITH shebang doesn't. Sometimes I need the former behaviour, so I omit shebang – giuliolunati Aug 27 '22 at 10:08
  • Another way of explaining it: To run an R script without the shebang in the script, we need to use `Rscript file.R`. But if the shebang is present in `file.R`, we can run it using `./file.R`. The equivalent in bash for a `file.sh` file is to run it with `sh file.sh`. – Nav Sep 14 '22 at 12:28
20

shebang line is needed in the file and only if it's meant to be run as executable (as opposed to sh file.sh invocation. It is not actually needed by script, it is for the system to know how to find interpreter.

EDIT: Sorry for misreading the question. If the shebang line is missing or not recognized, /bin/sh is used. But I prefer being explicit about the interpreter.

Note, that this behavior is not universal, IIRC, only some exec* family function do that (not to mention different platforms), so that's another reason to be explicit here.

Michael Krelin - hacker
  • 138,757
  • 24
  • 193
  • 173
  • 3
    The OP says he invokes the script as `./myscript.sh` - I would assume that means he is not explicitly using the shell as executable and script as argument. – Christian.K Sep 06 '12 at 08:56
  • yes. But the script is running without that line? Why? I am using `./myscript.sh` to run script. –  Sep 06 '12 at 08:56
  • @MichaelKrelin-hacker I was getting a "Exec format error" when running python that was invoking a shell script with no extension. Added the shebang line and the error is gone. Thanks to you explanation above, I now know why its good to be explicit. – Vaibhav Desai Sep 23 '13 at 06:48
  • 7
    *If the shebang line is missing or not recognized, `/bin/sh` is used.* Used by what; shell, kernel, something else? Is `/bin/sh` being used because of script's extension is `sh` or this doesn't matter? This answer is severely lacking. – Piotr Dobrogost Oct 08 '14 at 21:34
  • @PiotrDobrogost, I believe this is how `exec` call should work, whether the actual code reside may well be different on different systems (and in behaviour too, in practice). And I see no reason why assume the suffix matters unless explicitly stated. – Michael Krelin - hacker Oct 09 '14 at 06:23
4

The POSIX (Single UNIX Specification 4) standard is not helpful:

If the first line of a file of shell commands starts with the characters "#!" , the results are unspecified.

So, the standard implies that if you don't have #! then it should run a POSIX shell. But modern shells are not POSIX compliant. The old Korn Shell 88 (ksh88) ran the Bourne shell (close to a POSIX shell) with no #! line, but ksh93 breaks that, and so does Bash. With both ksh93 and Bash, they run their own shell if no #! line is present.

Despite popular opinion, Bash and Korn shells differ. When you write a shell script you can never be sure what shell you will be run from, or even if it will be run from another shell at all (most programming languages can run other programs). The minute you use something outside of Bourne/POSIX syntax you will be scuppered.

Always use a #! line, don't leave it to chance.

cdarke
  • 42,728
  • 8
  • 80
  • 84
  • 2
    Your statement about shell compliance is reversed. Modern shells like ksh and bash are POSIX compliant (or at least very close to) while the Bourne shell is definitely not. The initial POSIX standard for the shell was essentially ksh88. That makes reasonable for bash and ksh to run themselves when the standard states a POSIX compliant shell should be used. Bash, ksh88 and ksh93 definitely differ but the areas where they do are either unspecified behavior in the standard or outside its scope. – jlliagre Dec 11 '12 at 16:26
  • @jlliagre: POSIX says `sh` is run if there is no `#!`, not ksh or bash. When Bash runs a non-#! line script it does not run in POSIX mode (--posix) or as the sh symbolic link. POSIX might have been based on ksh88, but I specifically mentioned ksh93, which is considerably different from sh in the POSIX standard (there are differences between ksh88 and POSIX as well, typedef in functions for example), however it is true that, SFAIK, ksh93 is a super-set of POSIX sh (that's why typedef in functions changed from ksh88 to 93). I stand by my advise that it is wise to always specify a `#!` line. – cdarke Dec 12 '12 at 08:57
  • 1
    You incorrectly assume /bin/sh is always POSIX. POSIX doesn't say /bin/sh is run when there is no shebang but when you are already under a POSIX environment, a POSIX shell will interpret a script with no shebang. It doesn't mandate this shell to have a particular pathname. It is up to the implementor to define its name (probably sh) and path which might not be /bin like Solaris 10 /usr/xpg4/bin. That's why I advise portable shell scripts not to have a shebang, like the standard suggests. If your shell is bash running as POSIX mode and you call a non #! script, it will be run in POSIX mode too. – jlliagre Dec 12 '12 at 10:54
  • 2
    `If the first line of a file of shell commands starts with the characters "#!" , the results are unspecified.` I read that as `If "#!" then unspecified.`, but the rest of your answer suggests the opposite (`if no "#!" present then unspecified.`). Are you missing a negation? Otherwise, could you explain *in what case* **are** *the results* **specified**? – Suzanne Soy Sep 30 '13 at 08:23
  • 1
    @Georges Dupéron: No, the point is that POSIX does not specify what should happen with a #!. To answer your question in what case are the results specified, I suggest you read the POSIX standard. – cdarke Oct 01 '13 at 12:09
  • You cite *If the first line of a file of shell commands starts with the characters "#!" , the results are unspecified.* and then you state *So, the standard implies that if you don't have #! then it should run a POSIX shell.* which in no way is implied by the cited statement. – Piotr Dobrogost Oct 08 '14 at 22:08