I want to use python24 provided by ports, so I've installed it, and python_select -s shows that the version I want is indeed selected. Running which python gives /opt/local/bin/python, and running /opt/local/bin/python gives me the version I want. However when I run python from the shell, I get the /usr/bin/python version instead. I don't have a python alias.

Here's the situation in a nutshell:

  1. I believe the path is set up sensibly, and which python seems to confirm this.
  2. alias only returns 1 entry, which is something unrelated to this.

Nevertheless, running python from the bash shell gives me the wrong python!

I'm kind of stumped! What am I overlooking?

  • You did check your path to see which comes first: /usr/bin or /opt/local/bin ? – Jeremy L Apr 4 '10 at 17:04
  • yep, path was fine, as described below it was a matter of bash having stale information; the hash -d fixed it. – tramdas Apr 4 '10 at 17:09
  • Next time, try the Bash builtin type -a instead of the external which (you'll still need to do hash) – Dennis Williamson Apr 4 '10 at 18:01
  • I'm not sure if type -a does the trick, maybe hash -t instead? – tramdas Apr 5 '10 at 16:46

Try hash -d python. This will tell bash to forget where it last saw the python executable.

  • Wow that worked! Was about a minute from wiping out my MacOS install and doing a clean install since it was stuck at 2.5 and couldn't fix! – daveangel Apr 6 '12 at 20:24

Perhaps you just updated something and your bash instance has stale information about executables. Try exec bash.

When I:

  1. Start qqq (/usr/bin/qqq) from bash.
  2. Add something qqq to /usr/local/bin/.
  3. Try to start qqq again in the same bash.

It uses the already-looked-up version (/usr/bin/qqq)

However when I restart the bash, it looks for qqq again and gets /usr/local/bin/qqq.

  • Thanks Vi, what you suggested also worked, and your explanation was helpful. I have never encountered this problem before, I always thought which was "authoritative". – tramdas Apr 4 '10 at 17:06
  • which is a separate executable, not a bash internal command. The problem is a stale cache in bash. – Vi. Apr 4 '10 at 17:19

Another possibility is that the script itself specifies which Python executable to run in the first line of the script. For example, my system has Python 2.6 and 2.7 installed, and if the first line is something like:


then I get Python 2.6, even though 2.7 is the system default.

The usual way to specify the default is:

#!/usr/bin/env python

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.