executing python scripts that are symlinked

[Charles Smith]

Hi.

How can I say, from the cmd line, that python should take my CWD as my
CWD, and not the directory where the script actually is?


I have a python script that works fine when it sits in directory WC,
but if I move it out of WC to H and put a symlink from H/script to WC,
it doesn't find the packages that are in WC. Also, if I use the
absolute path to H, it won't find them, but I guess I can understand
that.

Someone said on the net that python doesn't know whether a file is
real or a symlink, but I think that somehow, python is able to find
out where the real file is and treat that as its base of operations.

Charles.

 

[Andrew Berg]

Hi.

How can I say, from the cmd line, that python should take my CWD as my
CWD, and not the directory where the script actually is?


I have a python script that works fine when it sits in directory WC,
but if I move it out of WC to H and put a symlink from H/script to WC,
it doesn't find the packages that are in WC. Also, if I use the
absolute path to H, it won't find them, but I guess I can understand
that.

Symlinks can find their targets, but targets have absolutely no way of knowing where symlinks to them are. It's one-way. It would work if
the actual file were in WC and you created a symlink inside H.

 

[Dave Angel]

Hi.

How can I say, from the cmd line, that python should take my CWD as my
CWD, and not the directory where the script actually is?


I have a python script that works fine when it sits in directory WC,
but if I move it out of WC to H and put a symlink from H/script to WC,
it doesn't find the packages that are in WC. Also, if I use the
absolute path to H, it won't find them, but I guess I can understand
that.

Someone said on the net that python doesn't know whether a file is
real or a symlink, but I think that somehow, python is able to find
out where the real file is and treat that as its base of operations.

You'd really better specify your environment - exact OS and Python
version. symlink and cwd usually imply a Unix-type system, but cmd is a
Windows thing.

Then give examples of what your cwd is, what string you're typing at the
shell prompt, and what's happening.

For example windows is good at changing cwd long before the executable
gets control, in some situations.

 

[Charles Smith]

You'd really better specify your environment - exact OS and Python
version.  symlink and cwd usually imply a Unix-type system, but cmd is a
Windows thing.

Then give examples of what your cwd is, what string you're typing at the
shell prompt, and what's happening.

Well, I'm on a ubuntu platform, running subversion, but I can't commit
this debugging tool into the working copy where I'm using it, so I
maintain it in my home directory. The tool does use production
packages, though.

So, if I say,

$ python fapi-test.py

and fapi-test.py really is there, then it works, using the codec
production package. But if I use a symlink instead, it says

Traceback (most recent call last):
File "test2", line 1, in <module>
from codec.support import *
ImportError: No module named codec.support


Python tells me Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)

 

[Steven D'Aprano]

Hi.

How can I say, from the cmd line, that python should take my CWD as my
CWD, and not the directory where the script actually is?

*scratches head*

Python does use your current working directory as your current working
directory. I think you are misdiagnosing the problem.

Here's a demonstration:

steve@runes:~$ cat test.py
import os
print os.getcwd()


steve@runes:~$ ln -s ~/test.py /tmp/test
steve@runes:~$ ls -l /tmp/test
lrwxrwxrwx 1 steve steve 19 May 16 18:58 /tmp/test -> /home/steve/test.py
steve@runes:~$ cd /etc/
steve@runes:/etc$ python /tmp/test
/etc

I have a python script that works fine when it sits in directory WC, but
if I move it out of WC to H and put a symlink from H/script to WC, it
doesn't find the packages that are in WC. Also, if I use the absolute
path to H, it won't find them, but I guess I can understand that.

The obvious solution is to make sure that WC is in the Python path. You
can do that by adding it the environment variable PYTHONPATH, or by
adding it to sys.path at the start of your script. I think you can also
use a .pth file as well.

Another solution may be to add this to the beginning of your script:

os.setcwd('path/to/WC')

but that's a crappy solution, you generally don't want to be changing the
working directory from inside scripts if you can avoid it.

 

[Charles Smith]

Python does use your current working directory as your current working
directory. I think you are misdiagnosing the problem.

That's usually how it ends up ...

Here's a demonstration:

steve@runes:~$ cat test.py
import os
print os.getcwd()

steve@runes:~$ ln -s ~/test.py /tmp/test
steve@runes:~$ ls -l /tmp/test
lrwxrwxrwx 1 steve steve 19 May 16 18:58 /tmp/test -> /home/steve/test.py
steve@runes:~$ cd /etc/
steve@runes:/etc$ python /tmp/test
/etc

You're right. I can believe that python doesn't really change it's
notion of the CWD.

It seems like when I'm in WC and invoke ./script (which is symlinked
to H/script), python says, "I have a specification somewhere that says
I can look for modules where my script is, and since I'm really smart,
I happen to know that I'm in WC but the script is not, but is really
in H, where the stupid operator better have his packages set up"

The obvious solution is to make sure that WC is in the Python path. ....

but that's a crappy solution,

Right. Other tools don't try to figure out what I really want to do
with a symlink, but just accept that it's a file. Python should do
the same ...

But, as you say, I'm surely misdiagnosing the problem.

 

[Dave Angel]

Well, I'm on a ubuntu platform,

Good. Linux seldom gets in the way.

running subversion, but I can't commit
this debugging tool into the working copy where I'm using it, so I
maintain it in my home directory. The tool does use production
packages, though.

So, if I say,

$ python fapi-test.py

and fapi-test.py really is there,

where? Be explicit. When copying the python invocation line above, you
never bothered to include the current directory that's generally
displayed right in front of that $ prompt.

then it works, using the codec
production package.

What codec production package. And where is it installed? And how do
you intend that Python find it?

But if I use a symlink instead,

So you delete the pfapi-tst.py out of the current directory, and create
instead a symlink in the current directory that points to its real
location And without changing current directory, you run the same
command and it runs till it gets to the import line, at which point it
gives a traceback that has nothing to do with the file you're running???
The traceback thinks you're running test2.py.

it says

Traceback (most recent call last):
File "test2", line 1, in <module>
from codec.support import *
ImportError: No module named codec.support


Python tells me Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)

Take a look at Stephen's example. He runs some things, shows you
exactly what he's running, and what happens. The things he runs may not
match what you did, but we cannot tell.

From within your script, you can display os.getcwd(), you can ...


import sys, os
print "cwd is", os.getcwd()
print "file is", __file__
print "PATH is", os.getenv("PATH")
print "python-path is", os.getenv("PYTHONPATH")
print "sys.path is", sys.path

import codec
print "codec file is", codec.__file__

if you run that both as a regular file and on a symlink pointing to that
file, comparing the two runs could give you a clue as to what's
different. My suspicion is that you have a different cwd when you test
it the second way.