Fix for #932977: MacOSX does not pass the whole pathname in argv[0] for

#!-scripts, only the filename part, and this can lead to incorrect
initialization of sys.path and sys.executable if there is another python
on $PATH before the one used in #!.

The fix was picked up from the darwinports crowd, thanks!

1 files changed, 17 insertions, 0 deletions

diff --git a/Modules/getpath.c b/Modules/getpath.c
index 6559b06..b3921e3 100644
--- a/Modules/getpath.c
+++ b/Modules/getpath.c
@@ -374,6 +374,9 @@ calculate_path(void)
 #ifdef WITH_NEXT_FRAMEWORK
     NSModule pythonModule;
 #endif
+#ifdef __APPLE__
+    unsigned long nsexeclength = MAXPATHLEN;
+#endif
 
 	/* If there is no slash in the argv0 path, then we have to
 	 * assume python is on the user's $PATH, since there's no
@@ -382,6 +385,20 @@ calculate_path(void)
 	 */
 	if (strchr(prog, SEP))
 		strncpy(progpath, prog, MAXPATHLEN);
+#ifdef __APPLE__
+     /* On Mac OS X, if a script uses an interpreter of the form
+      * "#!/opt/python2.3/bin/python", the kernel only passes "python"
+      * as argv[0], which falls through to the $PATH search below.
+      * If /opt/python2.3/bin isn't in your path, or is near the end,
+      * this algorithm may incorrectly find /usr/bin/python. To work
+      * around this, we can use _NSGetExecutablePath to get a better
+      * hint of what the intended interpreter was, although this
+      * will fail if a relative path was used. but in that case,
+      * absolutize() should help us out below
+      */
+     else if(0 == _NSGetExecutablePath(progpath, &nsexeclength) && progpath[0] == SEP)
+       ;
+#endif // __APPLE__
 	else if (path) {
 		while (1) {
 			char *delim = strchr(path, DELIM);