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.
That is because a starting X session never reads your ~/.bashrc and ~/.profile. Usually, the desktop manager is started as root or its own user from an init script. The resulting process usually has the environment of the init process when it hits the desktop manager starting script. (I will not talk about less established init implementations at this point.)
After login it spawns a child process, which inherits just that environment. The child process drops privileges to your uid and runs /etc/X11/Xsession, which usually simply runs all the scripts in /etc/X11/Xsession.d. These scripts usually either set environment variables, or, specifically modify the invocation of the desktop environment.
In that directory you may find a file like 40x11-common_xsessionrc on Debian systems, which sources your ~/.xsessionrc. The last file in /etc/X11/Xsession.d will start your desktop environment. All your GUI processes will be spawned from this process, thus inherit the environment set up through /etc/X11/Xsession.d and consequently your ~/.xsessionrc.
~/.xsessionrc is a script file, which may source ~/.bashrc but that's really bad style, because then your DE sources it, the terminal process inherits that environment and then bash sources ~/.bashrc again, which may have unwanted side effects.
However, it is totally acceptible to have a ~/.myenvironmentvariables, which contains stricly (environment) variable definitions and is sourced by ~/.bashrc and ~/.xsessionrc. If you do that, all your processes will inherit the variables specified in ~/.myenvironmentvariables, especially the shell scripts you double click in Nautilus.
Best Answer
No. By the time a shebang comes into play, you have already lost. A shebang is applied when a process is
exec()'d and typically that happens after forking, so you're already in a separate process. It's not the shell that reads the shebang, it's the kernel.