"shebang /usr/bin/env python" invoking the wrong Python interpreter

Question

What's happening, here?!

$ /usr/bin/env which python
/home/dbanas/.local/bin/python

$ /home/dbanas/.local/bin/python -V
Python 2.7.3 -- EPD_free 7.3-2 (64-bit)

$ /usr/bin/env python -V
Python 2.4.3

I stumbled upon this, trying to debug one of my Python scripts, which uses a

#! /usr/bin/env python

first line. And I don't understand how it's possible.

Thanks! -db

I did just notice that '~/.local/bin/python' is a link, not an executable. Would that break the '/usr/bin/env ...' flow somehow?

Perhaps, this is a more succinct way to express the fundamental puzzle?:

$ env python -V
Python 2.4.3

$ python -V
Python 2.7.3 -- EPD_free 7.3-2 (64-bit)

It just keeps getting curioser and curioser:

$ which python
/home/dbanas/.local/bin/python

$ python -c 'import sys; print sys.executable'
/usr/bin/python

Answer 1

Most likely what's happening is you don't have your PATH variable exported to the environment. In that case, /usr/bin/env won't have a PATH set, and its execvp call will end up searching a small set of default directories (which typically includes /usr/bin, naturally).

To see this (in bash):

$ export PATH
$ declare -p PATH  # verify PATH is exported, denoted by the -x
declare -x PATH="<my usual path, omitted...>"
$ /usr/bin/env python -V  # shows my own python build
Python 2.7.6
$ export -n PATH  # un-export PATH
$ declare -p PATH
declare -- PATH="<my usual path, omitted...>"
$ /usr/bin/env python -V  # shows the system (/usr/bin/python) version
Python 2.6.6

So, in summary, make sure to export PATH somewhere in your shell dotfiles.

Answer 2

python seems to be an alias in your shell. Unalias it

unalias python

and try again.