strange subprocess behavior when calling ps

[Ned Deily]

In article 
<61496525-afab-4d19-a7e9-e61fb46e03ef at n30g2000vbb.googlegroups.com>,
 Roger Davis <rbd at hawaii.edu> wrote:
> First, I *still* don't quite understand why this happens with my 2.6.6
> interpreter but not my 2.6.1, and why another of the respondents to
> this thread (Chris) could not duplicate this problem with his own
> 2.6.6 environment. Is there something defective with my Python
> environment having to do with the 2.6.6 upgrade I installed directly
> from python.org? (Chris used Fink, apparently.) If so, how can I clean
> it up? I do have an easier time believing that this is a mangled
> installation issue now that the problem has essentially been reduced
> to the handling of an environment variable which I can well imagine
> could be easily garbled somewhere in a version mismatch scenario.

Interesting.  It appears that OS X 10.6 takes into account the 
deployment target of the executable.  Prior to 2.7, all recent 
python.org installed Pythons have been built with 
MACOSX_DEPLOYMENT_TARGET = 10.3, allowing the same build to work on all 
releases from 10.3.9 on.  So, when you launch a script with the 
python.org interpreter (with a 10.3 deployment target), OS X 
automatically sets COMMAND_MODE to 'legacy'.  The Apple-supplied Python 
2.6.1 in OS X 10.6 is built with a deployment target of 10.6, so it gets 
a COMMAND_MODE of 'unix2003'.  And, as far as I can tell, OS X 10.5 
honors COMMAND_MODE but does not automatically set it or tailor it like 
10.6 does.  Live and learn!

> Second, I do need to make this work on multiple platforms, primarily
> Linux in addition to the Mac but also with a potential variety of
> Python releases on both MacOS and Linux. I'm not sure if Linux will
> object to this COMMAND_MODE business, I guess I'll just have to try
> and see what happens. Any thoughts on that?

As far as I know, COMMAND_MODE has no special meaning on other platforms 
so it should be ignored anywhere but on OS X.  If you want to be extra 
cautious, you could test for 'sys.platform == 'darwin'.

 > Finally, to split hairs a bit concerning your suggested solution, I
> have a question about the additional env={'COMMAND_MODE': 'unix2003'}
> argument. This works for me, but my reading of the subprocess
> documentation leads me to believe that this will actually wipe out the
> entire environment that would otherwise be inherited from the parent
> and replace it with that single setting. I don't think this has any
> ill effects here with regard to ps, at least none I can detect at the
> moment, but wouldn't a perhaps safer solution be to do
> 
> os.environ['COMMAND_MODE']= 'unix2003'
> 
> prior to the Popen() to instead augment/correct the existing
> environment which will then later be inherited by the child, assuming
> no explicit env= optional argument is used? This also works for me,
> and I think I'm more inclined to go this route unless you can think of
> a good reason not to do so.

That analysis seems correct.  So it comes down to whether there are any 
environment variable settings the user could make that would positively 
or negatively affect the operation of your script.

-- 
 Ned Deily,
 nad at acm.org