In article <2fe1a73a-5bdd-45cd-8323-ccdf68df3...@ucsd.edu>, "Helly John J." <hel...@ucsd.edu> wrote: >[...] > 3. I changed the gdal_merge.py code so it uses the correct syntax > even after the error but then find that I get the original 'no module' > error, I think, because gdal_merge.py starts with the line: > > #!/usr/bin/env python > > I don't understand this usage but when I run it alone (i.e., /usr/bin/ > env) I see that it forces the PATH, and the environment in general, to > be something different than what I have set in my .bash_profile. For > example, it puts > > PATH=/Library/Frameworks/Python.framework/Versions/Current/bin: > > in the beginning in front of /usr/bin which I had moved up in the path > in my .bash_profile. I overcame this by getting rid of /usr/bin/env > and substituting /usr/bin/python.
See <http://en.wikipedia.org/wiki/Shebang_(Unix)>. The idea behind /usr/bin/env usage is to allow scripts to get around absolute paths and to be able to find the interpreter for the script by using the search order of $PATH. So, if the script with /usr/bin/env python was invoking the wrong python, it sounds like your $PATH wasn't really what you thought it was, despite changing your .bash_profile. Did you start a new terminal session or login shell? What does "echo $PATH" say? > So, there are three issues: > > 1. the malloc error > 2. the interaction with the gdal_merge.py error handling No suggestions on the first two, other than to perhaps install easy_install and GDAL and friends using the python.org 2.5 and/or to ask in a more specialized forum. > Otherwise, everything's peachy. Good luck! -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
