6

Python 2.7.3 on OSX 10.8.2

I'm currently writing a script that imports the markdown module. I used the #!/usr/bin/env python shebang for portability. The script runs fine when I run it directly in shell via ./myscript.py arg1

When I run the script from outside of a (login) shell, for example via AppleScript do shell script "/path/to/myscript.py " & quoted form of arg1, it fails with 

myscript.py", line 8, in <module> import markdown ImportError: No module named markdown

I guess that this might be a problem with the shebang, so I changed the shebang to my python location #!/usr/local/bin/python and sure enough the script worked fine.

So my question twofold:

  1. Why does using /usr/bin/env python break my import?
  2. How can I avoid this problem without having to use /usr/local/bin/python?
Improve this question
2
  • I don't think it's using /usr/bin/env python as much as using a non-login shell. I'm assuming that /usr/local/bin isn't on PATH in such a shell, or at least not before /usr/bin, which would explain why python in the latter is picked. Are you changing PATH in your bash config files? Commented Apr 7, 2013 at 23:54
  • A tidbit I left out is that both #!/usr/bin/env python and #!/usr/local/bin/python were working perfectly in TextWrangler, and both gave me identical results when run in Terminal. It was only calling it from AppleScript that produced the error (rodrigo is correct). While TextWrangler and Terminal both gave me identical results, I was able to see the difference by running do shell script "(echo 'import sys'; echo 'print sys.path';) | /usr/bin/env python" in AppleScript Editor. do shell script "which python" would have been even easier. Commented Apr 8, 2013 at 4:01

2 Answers 2

Reset to default
5

#!/usr/bin/env python means "go find python on $PATH as if it the shell were looking for it, and run that." So since you get different results, you are probably using different pythons.

To check, see if running /usr/local/bin/python and /usr/bin/env python give you the same pythons. You can also use type -a python to find every python on $PATH. On my system, type -a python gives:

python is /opt/local/bin/python python is /usr/bin/python python is /usr/local/bin/python

(That first one is installed by MacPorts.)

Anyway, as rodrigo points out, direct launching is probably not using the $PATH you expect. Which means using /usr/bin/env isn't going to work.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Your answer explains the nature of the problem, but not how to solve it.
The simplest solution is to use #!/usr/local/bin/python or change your AppleScript to do shell script "/usr/local/bin/python /path/to/myscript.py " & quoted form of arg1 .
I appreciate the information. Two other factors contributed to my confusion: one is that both /usr/local/bin/python and /usr/bin/env python appear to give me identical results -- I'm guessing this is because I'm running the command from a login shell either way. It could also be because I have identical versions of Python installed in both locations, as running those commands doesn't give me the path to python, only the version number.
Also thank you for the answer. By identifying the correct python in the AppleScript, I'm able to keep the #!/usr/bin/env python in the shebang of the python script, meaning the script is both functional on my system and portable for others. Perfect!
I didn't mean "run your program with both /usr/local/bin/python and /usr/bin/env python"; I meant run those directly to see what version number and build dates are reported.
|
1

Well, it looks like the PATH environment variable in your login shell is different than in the AppleScript process.

My guess is that you have a .profile file or similar with the line:

PATH=/usr/local/bin:$PATH

But that file is only executed if you open a shell, not from other processes. And obviously you have a different version of Python in /usr/bin/python that does not have the markdown module.

Improve this answer

4 Comments

Your answer explains the nature of the problem, but not how to solve it.
@JoshCaswell: You're right. The best solution would be to change the PATH system wide, or at least user wide, so that all the user processes have the same search path. But I'm afraid that the details are system specific, and the OP didn't say what he uses (something about apples, maybe).
Many thanks for the explanation. As stated at the beginning of the post, I'm using OSX 10.8.2. I may give a shot to changing my path for non-login shells.
The Python version and OS have been the first sentence in the post since the original revision.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.