[21:26] pwd-bug $cat m
#!/usr/bin/env python

from subprocess import Popen
Popen(["./t"], cwd="./p")
[21:26] pwd-bug $cat p/t 
#!/usr/bin/env python

from os import environ
print environ["PWD"]
[21:26] pwd-bug $python m 
/Users/mtebeka/playground/pwd-bug

The output should be /Users/mtebeka/playground/pwd-bug/p

In most shells $PWD is a magic variable that is maintained by the shell 
itself. 

IMHO python has no reason to mess with variables that happen to be defined 
by some shells. If subprocess were to set $PWD, os.setuid should set $UID, 
and there may be other magic variables as well.

I can see your point, though I think particularly in this case it's
(unfortunately) fairly common that scripts on POSIX platforms read $PWD
instead of finding the current working directory properly. 

I'm probably not the first person that has had to set PWD explicitly in
a python program for this reason. Yes, it's really the fault of the
people who maintain the script I'm calling, but I don't think setting
PWD on POSIX could have any bad effects and should surely be easy to do?

On 26 Nov, 2009, at 19:27, Geoffrey Bache wrote:

> 
> Geoffrey Bache <gjb1002@users.sourceforge.net> added the comment:
> 
> I can see your point, though I think particularly in this case it's
> (unfortunately) fairly common that scripts on POSIX platforms read $PWD
> instead of finding the current working directory properly. 
> 
> I'm probably not the first person that has had to set PWD explicitly in
> a python program for this reason. Yes, it's really the fault of the
> people who maintain the script I'm calling, but I don't think setting
> PWD on POSIX could have any bad effects and should surely be easy to do?

Shouldn't the script set $PWD itself? AFAIK shells like bash will set $PWD regardless of whether they are running as an interactive shell or as a shellscript.

Reading os.environ['PWD'] in a Python script not a good example of whey the proposed functionality might be useful because there are a number of ways to change the current working directory without affecting os.environ. For example using os.chdir, or even an extensions that calls the chdir system call directly.

Ronald

You misunderstand: I am not reading $PWD. I need to call a C program as
a subprocess, which is written by a third party and which determines its
current working directory by reading $PWD. os.chdir will not have any
effect on this script, nor will passing "cwd" to "subprocess.call". I
have to write os.environ["PWD"] = os.getcwd() in my code before it will
work.

Not only that, but of course I have to know about $PWD and the fact that
some people use it. Otherwise it just seems like Python isn't correctly
passing on the current working directory.

What if you pass shell=True to the subprocess call?

I tried that and it didn't work, though not for this reason. I'm also
trying to read the output from the subprocess via a pipe and that wasn't
being collected for some reason. I didn't really track down why so far,
if it makes or breaks this bug I can do so though.

`Popen` is the wrong place to implement this functionality.  It may be
reasonable to introduce a higher-level wrapper API which does this sort
of thing.  Consider that if `Popen` itself does it, though, then there
is no way to launch a process with a particular working directory
*without* PWD set in its environment.

I agree that this is not something that Popen should be doing.  If you
need the environment variable set, the correct thing to do is what you
did: set it in the environment you pass to Popen.