[MrStonedOne]

'python' might not be a valid command because 'python3' exists and 'python' does not.

When designing things for 'just work' scripts you have to take esoteric environments into account.

There is no guarantee that '#!/usr/bin/env python' will not error in an environment with only python3 installed.

[jfrunyon]

There is also no guarantee that Python is installed at all, and there is no guarantee that it is on the path even if it is installed.

[stavros]

Are you sure? AFAIK python points to the default Python, be that 2 or 3.

[MrStonedOne]

so, i haven't had this with python, but i have a webserver i manage right now where there are 3 versions of php installed, and `php` as a command returns command not found. This came about when the default version was uninstalled as insecure, but was intentionally not fixed because nothing broke (since fpm managed all of this anyways) and cronjobs were already using the versioned command names and having it error ensures thought is being done into the php version the code runs.

So I do wonder how many distros (and manual install workflows) for python could cause this to happen if python2 got uninstalled from a system that had both, where python get removed, rather then updated to point to python3.

[nomel]

It's the other way around, in all systems I've found. python3 (or python3.x) is the actual executable, with python being a symlink to, usually, python 2.

[stavros]

Sorry, typo. I meant to say `python` is a symlink to the default Python (you can sometimes change the default Python), but it'll almost always exist and point to a valid interpreter.