Fedora ships numerous executables written in Python. Many of them contain the shebang line: #!/usr/bin/env python
However, this makes it difficult to install alternative versions of Python on the system. If a user wishes e.g. to install python 3 on the system, and have a /usr/local/python in her PATH, this will break these executables.
These system executables are expecting to use the system python, and thus should use: #!/usr/bin/python."
Last line of this fragment says clearly that #!/usr/bin/python should be used.
In other cases .. rpm it is not IPS (Solaris packages management software) which is able switch between for example python versions performing modules dependencies verification, resolution and repointing on switching for example between python 2.x an python 3.x allowing or not such operation as some dependencies will be not broken.
As long as rpm has no such functionalities env is not a solution. It may be only nothing more than workaround causing even more problems as side effect.
In other words IMO if someone has some impression that without extending rpm in similar way as it is with IPS he.she may be right .. it is only impression that it is true.
/
If env is used here in such transition scenarios (which so far I don't see that it is the case) any python related issues may start growing up as someone will decide to put own version of the python in let's say /usr/local/sbin not aware that because someone/something changed system $PATH putting on the fron /usr/local/sbin all python scripts executed from tty sessions will be no longer using python from packages but this one installed manually.
He/she will be frustrated and in case of using some commercial support some other guys will be witness of some "sex in the office" ("still I don't know what but something is f*ing around!?!")
This is now very possible case as someone decided to add in /etc/profile:
pathmunge () {
case ":${PATH}:" in
*:"$1":*)
;;
*)
if [ "$2" = "after" ] ; then
PATH=$PATH:$1
else
PATH=$1:$PATH
fi
esac
}
[..]
# Path manipulation
if [ "$EUID" = "0" ]; then
pathmunge /usr/sbin
pathmunge /usr/local/sbin
else
pathmunge /usr/local/sbin after
pathmunge /usr/sbin after
fi
and by this by root and non root users on the front of the $PATH have /usr/local/bin and/or /us/local/sbin
Only this is nothing more than asking for yet another dimension of troubles with using env as in none of those "additional" paths are any resources provided by distribution :->
Sometimes people are altering system $PATH by adding own scripts in /etc/profile.d/
All those quite possible now bad cases could be avoided by dropping use env in scripts provided by distro packages.
Just discovered that /root/.bash_profile from rootfiles adds " PATH=$PATH:$HOME/bin" and /etc/skel/.bash_profile addes. "PATH=$PATH:$HOME/.local/bin:$HOME/bin".
[mode=sarcasm]
These are really brilliant ideas!!!
Especially this part in /etc/profile about $PATH is .. mind blowing!!!
[/mode]
I would be really interested explanation what was behind all those $PATH alteration.
"/sbin Essential system binaries, e.g., fsck, init, route."
"/usr/sbin Non-essential system binaries, e.g., daemons for various network-services."
Hmm .. Fedora dropped some essential FHS compliance parts providing /sbin content for non-root users on the $PATH??
----
Back to the env subject related to quoted from web page paragraph.
Nevertheless all cases which I've checked so fat are not about provide possibility switching between python versions because only one of the python packages provides provides python, python2 or python3. All those cases are related to use python in fixed location as it is in Fedora and most of the Linux distros.
$ rpm -ql python3 |grep bin
/usr/bin/pydoc3
/usr/bin/pydoc3.6
/usr/bin/python3
/usr/bin/python3.6
/usr/bin/python3.6m
/usr/bin/pyvenv
/usr/bin/pyvenv-3.6
$ rpm -ql python2 |grep bin
/usr/bin/pydoc
/usr/bin/pydoc2
/usr/bin/pydoc2.7
/usr/bin/python
/usr/bin/python2
/usr/bin/python2.7
BTW: pydoc it is more needed by someone who is just writing python code than using it.
Probably it would be good to put pydoc in devel as pydoc can be started in service mode providing over http documentation browsing services probably such thing should not be by default installed on prod hosts (now is hard to avoid this).