Shell – Why is #!/usr/bin/env bash not working on the system

environment-variablesshebangshell-script

I ran into some issues when running some installation scripts where they complained of bad interpreter.

So I made a trivial example but I can't figure out what the problem is, see below.

#!/usr/bin/env bash
echo "hello"

Executing the script above results in the following error

[root@ech-10-24-130-154 dc-user]# ./junk.sh
bash: ./junk.sh: /usr/bin/env: bad interpreter: No such file or directory

The /usr/bin/env file exists, see below:

[root@ech-10-24-130-154 dc-user]# ls -l /usr/bin/env
lrwxrwxrwx 1 root root 13 Jan 27 04:14 /usr/bin/env -> ../../bin/env
[root@ech-10-24-130-154 dc-user]# ls -l /bin/env
-rwxr-xr-x 1 root root 23832 Jul 16  2014 /bin/env
[root@ech-10-24-130-154 dc-user]#

If I alter the script to use the regular shebang #!/bin/bash it works no problem. #!/bin/env bash works as well.

What is missing from the environment to allow the portable shebang to work?

ls -lL /usr/bin/env returns ls: cannot access /usr/bin/env: No such file or directory so I guess I need to alter the symbolic link? Can I point it to /bin/env?

env --version is 8.4 and the OS is Red Hat Enterprise Linux Server release 6.6.

Best Answer

ls -lL /usr/bin/env shows that the symbolic link is broken. That explains why the shebang line isn't working: the kernel is trying, and obviously failing, to execute a dangling symbolic link.

/usr/bin/env -> ../../bin/env is correct if /usr and /usr/bin are both actual directories (not symlinks). Evidently this isn't the case on your machine. Maybe /usr is a symbolic link? (Evidently it isn't a symbolic link to /, otherwise /usr/bin/env would be the same file as /bin/env, not a symbolic link).

You need to fix that symbolic link. You can make it an absolute link:

sudo ln -snf /bin/env /usr/bin/env

You can make it a relative link, but if you do, make sure it's correct. Switch to /usr/bin and run ls -l relative/path/to/bin/env to confirm that you've got it right before creating the symlink.

This isn't a default RHEL setup, so you must have modified something locally. Try to find out what you did and whether that could have caused other similar problems.

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.

Best Answer

Related Solutions

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

Objective Criteria/Requirements:

Testing:

Conclusion:

Related Question