up vote 5 down vote favorite
1
share [g+] share [fb]

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?

link|improve this question
You did check your path to see which comes first: /usr/bin or /opt/local/bin ? – Nerdling 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
feedback

2 Answers

up vote 9 down vote accepted

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

link|improve this answer
That fixed it, thanks. – tramdas Apr 4 '10 at 17:05
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 at 20:24
feedback
up vote 2 down vote

May be have just updated something and your has 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 already looked up version (/usr/bin/qqq)

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

link|improve this answer
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
feedback

Your Answer

 
or
required, but never shown
discard

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