shebang strange thing...

Brian Lenihan brian_l at yahoo.com
Thu Jun 26 11:34:09 CEST 2003


Michael Coleman <mkc at stowers-institute.org> wrote in message news:<85el1hpz0c.fsf at stowers-institute.org>...
> brian_l at yahoo.com (Brian Lenihan) writes:
> > If you have two or more Python installations, the first one in
> > your path gets invoked no matter what the shebang line says.
> > 
> > If the first line of a script is #!/usr/local/bin/python, I expect the
> > interpreter located in /usr/local/bin to execute the script, not the
> > one in /usr/bin, or the one in /sw/bin, but that is what you get if
> > you run the script as an executable.
> > 
> > The process list shows why - python is called without a path, e.g. as
> > "python".  The same behavior occurs if the shell is bash or tcsh.
> > As far as I know, OS X is the only "modern" Unix to behave this way.
> 
> Tru64 (5.1) also shows this behavior (which recently bit me too), but
> it's arguably a bug in Python rather than in the OS.  If you look
> carefully, I think you'll find that the correct binary (e.g.,
> /usr/local/bin/python) is in fact being invoked, but that that binary
> then uses the libraries associated with the first python in your PATH.
> The reason this is happening is that python determines where all of
> its libraries live by examining argv[0], if a more suitable method is
> not available.  If this gives the full path, everything is fine, but
> if only the basename is given ("python"), then the startup code walks
> to the PATH to guess.  As you've noticed, in some cases, this guess is
> wrong.

I never use True64, but my company does, so I'm glad you identified
the same problem on that platform. argv[0] should contain the full
path to the interpreter and it does not, which makes me believe
this is an OS error, not a Python error, except you could argue that
relying on argv is not a platform independent way to find the
correct path.

If I could get the Panther install CD to boot on my PowerBook, I
could see if this is still going to be a problem in the future.




More information about the Python-list mailing list