[ python-Bugs-1387483 ] sys.path[0] when executed thru a symbolic link

[SourceForge.net]

Bugs item #1387483, was opened at 2005-12-21 18:23
Message generated for change (Comment added) made by kowaltowski
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Tomasz Kowaltowski (kowaltowski)
Assigned to: Jack Jansen (jackjansen)
Summary: sys.path[0] when executed thru a symbolic link

Initial Comment:
Under certain conditions there is a difference between
Mac OS X and Linux (both 2.4.1) with regard to the
value of the variable sys.path[0] which should contain
the directory from which the script was called.

This difference appears when the script is called
through a symbolic link by a different user. See the
attached example. It should be executed once by the
owner of the TESTPATH directory:

   ~/TESTPATH/sub1/testpath.py
and
   ~/TESTPATH/sub2/testpath.py

In both cases, under Linux and Mac OS X, the result is:

   /home/owner/TESTPATH/sub1

If a different user executes:

   ~owner/TESTPATH/sub1/testpath.py
and
   ~owner/TESTPATH/sub2/testpath.py

he gets the same results under Linux:

   /home/owner/TESTPATH/sub1

but two different results under Mac OS:

   /Users/owner/TESTPATH/sub1
and
   /Users/owner/TESTPATH/sub2

This seems like a minor problem but it breaks my
application because sys.path[0] is the first place to
look for imports!

I am not sure whether this is a Python problem or
something to do with the Mac OS X. My Mac OS X version
is 10.4.3.

----------------------------------------------------------------------

>Comment By: Tomasz Kowaltowski (kowaltowski)
Date: 2005-12-22 09:40

Message:
Logged In: YES 
user_id=185428

(1) I think it is a problem because under Mac OS X the user
#2 sees "sub2" (and not "sub1"!) as the working directory,
which is where it is different from Linux.

(2) The problem persists even if all permissions are open.

(3) The implementation of "os.readlink" migh be the right
clue about the problem: when the user #2 executes
"os.readlink("/Users/owner/TESTPATH/sub2/testpath.py") the
answer under Mac OS X is:

OSError: [Errorno 13] Permission denied:
'/Users/owner/TESTPATH/sub2/testpath.py'

even though all permissions are open.

Under Linux I get the expected answer: "../sub1/testpath.py".

Obviously there is a problem under Mac OS X, and this matter
should be reopen.



----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2005-12-21 18:39

Message:
Logged In: YES 
user_id=45365

I don't see this problem: both users see "sub1" as the working directory. Also 
on 10.4.3.

My guess: there is some problem with the readlink() call that Python uses to 
obtain the real pathname of the script (this is how it finds out sub2/
testpath.py is really sub1/testpath.py. Easy to test: fire up Python as user 2 
and do os.readlink("/Users/owner/TESTPATH/sub2").

I wouldn't be surprised if it is some sort of permission problem (maybe /
Users/owner being mode rwx--x--x so the readlink can't traverse through 
it?).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1387483&group_id=5470