Path: csiph.com!usenet.pasdenom.info!news.etla.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Thu, 16 May 2013 10:45:21 -0400
From: Dave Angel <davea@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: executing python scripts that are symlinked
References: <95bc1155-0a83-4ab1-8b76-68a819b2e29a@en2g2000vbb.googlegroups.com> <mailman.1741.1368692298.3114.python-list@python.org> <8640d5b0-5e6e-4a54-9584-6e7ffcdf1389@k3g2000vbn.googlegroups.com>
In-Reply-To: <8640d5b0-5e6e-4a54-9584-6e7ffcdf1389@k3g2000vbn.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1755.1368715536.3114.python-list@python.org>
Lines: 97
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:45427

On 05/16/2013 04:29 AM, Charles Smith wrote:
> On 16 Mai, 10:18, Dave Angel <da...@davea.name> wrote:
>> On 05/16/2013 03:48 AM, Charles Smith wrote:
>>
>>> 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.
>
>
> 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.

-- 
DaveA