Shebang – Does It Determine the Shell Running the Script?

executablescriptingshebang

This may be a silly question, but I ask it still. If I have declared a shebang

#!/bin/bash

in the beginning of my_shell_script.sh, so do I always have to invoke this script using bash

[my@comp]$bash my_shell_script.sh

or can I use e.g.

[my@comp]$sh my_shell_script.sh

and my script determines the running shell using the shebang? Is it the same happening with ksh shell? I'm using AIX.

Best Answer

The shebang #! is an human readable instance of a magic number consisting of the byte string 0x23 0x21, which is used by the exec() family of functions to determine whether the file to be executed is a script or a binary. When the shebang is present, exec() will run the executable specified after the shebang instead.

Note that this means that if you invoke a script by specifying the interpreter on the command line, as is done in both cases given in the question, exec() will execute the interpreter specified on the command line, it won't even look at the script.

So, as others have noted, if you want exec() to invoke the interpreter specified on the shebang line, the script must have the executable bit set and invoked as ./my_shell_script.sh.

The behaviour is easy to demonstrate with the following script:

#!/bin/ksh
readlink /proc/$$/exe

Explanation:

#!/bin/ksh defines ksh to be the interpreter.
$$ holds the PID of the current process.
/proc/pid/exe is a symlink to the executable of the process (at least on Linux; on AIX, /proc/$$/object/a.out is a link to the executable).
readlink will output the value of the symbolic link.

Example:

Note: I'm demonstrating this on Ubuntu, where the default shell /bin/sh is a symlink to dash i.e. /bin/dash and /bin/ksh is a symlink to /etc/alternatives/ksh, which in turn is a symlink to /bin/pdksh.

$ chmod +x getshell.sh
$ ./getshell.sh 
/bin/pdksh
$ bash getshell.sh 
/bin/bash
$ sh getshell.sh 
/bin/dash

Objective Criteria/Requirements:

In determining whether to use an absolute or logical (/usr/bin/env) path to an interpreter in a she-bang, there are (2) key considerations:

a) The interpreter can be found on target system

b) The correct version of interpreter can be found on target system

If we AGREE that "b)" is desirable, we also agree that:

c) It's preferable our scripts fail rather than execute using an incorrect interpreter version and potentially achieve inconsistent results.

If we DON'T AGREE that "b)" matters, then any interpreter found will suffice.

Testing:

Since using a logical path- /usr/bin/env to the interpreter in the she-bang is the most extensible solution allowing the same script to execute successfully on target hosts with different paths to the same interpreter, we'll test it- using Python due to its' popularity- to see if it meets our criteria.

Does /usr/bin/env live in a predictable, consistent location on POPULAR (not "every") Operating Systems? Yes:

RHEL 7.5
Ubuntu 18.04
Raspbian 10 ("Buster")
OSX 10.15.02

Below Python script executed both inside and outside of virtual envelopes (Pipenv used) during tests:
```
#!/usr/bin/env pythonX.x
import sys
print(sys.version)
print('Hello, world!')
```
The she-bang in the script was toggled by Python version number desired (all installed on same host):

#!/usr/bin/env python2
#!/usr/bin/env python2.7
#!/usr/bin/env python3
#!/usr/bin/env python3.5
#!/usr/bin/env python3.6
#!/usr/bin/env python3.7

Expected results: that print(sys.version) = env pythonX.x. Each time ./test1.py was executed using a different installed Python version, the correct version specified in the she-bang was printed.
Testing Notes:

Tests were exclusively limited to Python
Perl: Like Python- MUST live in /usr/bin according to the FHS
I've not tried every possible combination on every possible number of Linuxy/Unixy Operating System and version of each Operating System.

Conclusion:

Although it's TRUE that #!/usr/bin/env python will use the first version of Python it finds in the user's Path, we can moderate this behaviour by specifying a version number such as #!/usr/bin/env pythonX.x. Indeed, developers don't care which interpreter is found "first", all they care about is that their code is executed using the specified interpreter they know to be compatible with their code to ensure consistent results- wherever that may live in the filesystem...

In terms of portability/flexibility, using a logical- /usr/bin/env - rather than absolute path not only meets requirements a), b) & c) from my testing with different versions of Python, but also has the benefit of fuzzy-logic finding the same version interpreter even if they live at different paths on different Operating Systems. And although MOST distros respect the FHS, not all do.

So where a script will FAIL if binary lives in different absolute path then specified in shebang, the same script using a logical path SUCCEEDS as it keeps going until it finds a match, thereby offering greater reliability & extensibility across platforms.

Bash – Run a script on multiple shells

It would probably be easier to have two separate versions of the script. Since it is short it may not be worth adding extra code to handle the differences between the two formats as jw013 suggested. On the other hand if you had a larger script it would probably be easier to have one and make the script execute different commands depending on where it is running from.

Best Answer

Related Solutions

Shebang Best Practices – Why Use ‘#!/usr/bin/env NAME’?

Objective Criteria/Requirements:

Testing:

Conclusion:

Bash – Run a script on multiple shells

Related Question