20

How and who determines what executes when a Bash-like script is executed as a binary without a shebang?

I guess that running a normal script with shebang is handled with binfmt_script Linux module, which checks a shebang, parses command line and runs designated script interpreter.

But what happens when someone runs a script without a shebang? I've tested the direct execv approach and found out that there's no kernel magic in there - i.e. a file like that:

$ cat target-script
echo Hello
echo "bash: $BASH_VERSION"
echo "zsh: $ZSH_VERSION"

Running compiled C program that does just an execv call yields:

$ cat test-runner.c
void main() {
        if (execv("./target-script", 0) == -1)
                perror();
}
$ ./test-runner
./target-script: Exec format error

However, if I do the same thing from another shell script, it runs the target script using the same shell interpreter as the original one:

$ cat test-runner.bash
#!/bin/bash
./target-script

$ ./test-runner.bash 
Hello
bash: 4.1.0(1)-release
zsh: 

If I do the same trick with other shells (for example, Debian's default sh - /bin/dash), it also works:

$ cat test-runner.dash   
#!/bin/dash
./target-script

$ ./test-runner.dash 
Hello
bash: 
zsh: 

Mysteriously, it doesn't quite work as expected with zsh and doesn't follow the general scheme. Looks like zsh executed /bin/sh on such files after all:

greycat@burrow-debian ~/z/test-runner $ cat test-runner.zsh 
#!/bin/zsh
echo ZSH_VERSION=$ZSH_VERSION
./target-script

greycat@burrow-debian ~/z/test-runner $ ./test-runner.zsh 
ZSH_VERSION=4.3.10
Hello
bash: 
zsh: 

Note that ZSH_VERSION in parent script worked, while ZSH_VERSION in child didn't!

How does a shell (Bash, dash) determines what gets executed when there's no shebang? I've tried to dig up that place in Bash/dash sources, but, alas, looks like I'm kind of lost in there. Can anyone shed some light on the magic that determines whether the target file without shebang should be executed as script or as a binary in Bash/dash? Or may be there is some sort of interaction with kernel / libc and then I'd welcome explanations on how does it work in Linux and FreeBSD kernels / libcs?

Craig M. Brandenburg
  • 3,354
  • 5
  • 25
  • 37
GreyCat
  • 16,622
  • 18
  • 74
  • 112
  • 4
    This is a good question about shell internals and worth finding out the answer. However, to all readers I say: in practice, **don't**. Use a shebang. – Tom Zych Sep 01 '11 at 10:28
  • It might be simpler to just run `target-script` with different shells directly (like `bash target-script` or `dash target-script`) instead of creating a test runner for each shell. This should give the same results. – Piotr Dobrogost Oct 08 '14 at 23:05
  • *I've tested the direct execv approach and found out that there's no kernel magic in there*. Well, your `target-script` does not have shebang line so what kernel magic would you expect here? If you wanted to test kernel magic then you should have put shebang line in your script (just for this test). – Piotr Dobrogost Oct 08 '14 at 23:11
  • i prefer the questions/answers from here: https://stackoverflow.com/q/12296308/52074 because the linked question has more upvotes for both the question/answer and the writing is better for both IMO. – Trevor Boyd Smith Jan 18 '19 at 13:46
  • 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:06

2 Answers2

19

Since this happens in dash and dash is simpler, I looked there first.

Seems like exec.c is the place to look, and the relevant functionis are tryexec, which is called from shellexec which is called whenever the shell things a command needs to be executed. And (a simplified version of) the tryexec function is as follows:

STATIC void
tryexec(char *cmd, char **argv, char **envp)
{
        char *const path_bshell = _PATH_BSHELL;

repeat:

        execve(cmd, argv, envp);

        if (cmd != path_bshell && errno == ENOEXEC) {
                *argv-- = cmd;
                *argv = cmd = path_bshell;
                goto repeat;
        }
}

So, it simply always replaces the command to execute with the path to itself (_PATH_BSHELL defaults to "/bin/sh") if ENOEXEC occurs. There's really no magic here.

I find that FreeBSD exhibits identical behavior in bash and in its own sh.

The way bash handles this is similar but much more complicated. If you want to look in to it further I recommend reading bash's execute_command.c and looking specifically at execute_shell_script and then shell_execve. The comments are quite descriptive.

sorpigal
  • 25,504
  • 8
  • 57
  • 75
  • 2
    Thanks! I should note that comments in `execute_shell_script` are somewhat misleading: there is no real "executive mode" bit check, it all relies on `execve()` returned value and, what's more complex, bash also tries to emulate shebang parsing by itself, i.e. it doesn't just run whatever it gets as a script, but tries to find and run an interpreter, as specified in shebang. This functionality is somewhat useless in Linux, as `binfmt_script` already handles it at kernel level, but probably it's helpful for some other OS?.. – GreyCat Sep 01 '11 at 17:21
  • @GreyCat: At the least I expect it to be useful in a Windows port, so yes. – sorpigal Sep 01 '11 at 20:11
  • 2
    @GreyCat *there is no real "executive mode" bit check, it all relies on `execve()` returned value* According to execve(3) man page, the exec functions shall fail with `EACCESS` error if *Search permission is denied for a directory listed in the new process image file's path prefix, **or the new process image file denies execution permission**, or the new process image file is not a regular file and the implementation does not support execution of files of its type.* As *execution permission* depends on execution bit set one might say that this bit is being checked albeit not directly :) – Piotr Dobrogost Oct 08 '14 at 22:51
9

(Looks like Sorpigal has covered it but I've already typed this up and it may be of interest.)

According to Section 3.16 of the Unix FAQ, the shell first looks at the magic number (first two bytes of the file). Some numbers indicate a binary executable; #! indicates that the rest of the line should be interpreted as a shebang. Otherwise, the shell tries to run it as a shell script.

Additionally, it seems that csh looks at the first byte, and if it's #, it'll try to run it as a csh script.

Tom Zych
  • 13,329
  • 9
  • 36
  • 53
  • 1
    *the shell first looks at the magic number (first two bytes of the file)* No, it doesn't according to the FAQ entry you gave link to. Shell first tries to execute script as a binary and it's up to kernel to look at the magic number. Only after the script failed to execute this way the shell tries to run it as a script – *If execl() is successful in starting the program then the code beyond the execl() is never executed.* – Piotr Dobrogost Oct 08 '14 at 22:33
  • @PiotrDobrogost: You have a point. I was a bit careless there. But the rest of the entry shows that it's even more complex than that; `csh` does look at the first byte (not two bytes). Also worth noting is that the entry is about as old as the first Linux kernel, so things may well have changed. – Tom Zych Oct 13 '14 at 11:17