7

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?

4
  • You did check your path to see which comes first: /usr/bin or /opt/local/bin ?
    – Jeremy L
    Apr 4, 2010 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, 2010 at 17:09
  • Next time, try the Bash builtin type -a instead of the external which (you'll still need to do hash) Apr 4, 2010 at 18:01
  • I'm not sure if type -a does the trick, maybe hash -t instead?
    – tramdas
    Apr 5, 2010 at 16:46

3 Answers 3

12

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

1
  • 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, 2012 at 20:24
3

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.

2
  • 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, 2010 at 17:06
  • which is a separate executable, not a bash internal command. The problem is a stale cache in bash.
    – Vi.
    Apr 4, 2010 at 17:19
0

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:

#!/usr/bin/Python-2.6.8/bin/python

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .