Mercurial > cpython-lru_cache-weakref
diff Modules/getpath.c @ 32230:6fc8827c403c 2.3
Backport of 1.47:
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!
| author | Jack Jansen <jack.jansen@cwi.nl> |
|---|---|
| date | Thu, 03 Jun 2004 14:38:38 +0000 |
| parents | beea42152787 |
| children | 8101e8d24f05 472023d0a10d |
line wrap: on
line diff
--- a/Modules/getpath.c Thu Jun 03 14:16:53 2004 +0000 +++ b/Modules/getpath.c Thu Jun 03 14:38:38 2004 +0000 @@ -374,6 +374,9 @@ #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 @@ */ 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);