[Pythonmac-SIG] Environment variable issues running py2app application

[Ronald Oussoren]

On 25 Apr, 2013, at 10:41, Paul Wiseman <poalman at gmail.com> wrote:

> On 24 April 2013 19:29, Ned Deily <nad at acm.org> wrote:
> In article
> <CACgdh2jujjuvueKOXpr2e4utJe3ZdYad8OX9JCFFpLhgHbXAKA at mail.gmail.com>,
>  Paul Wiseman <poalman at gmail.com> wrote:
> > I've never seen this problem before but one user seems to be experiencing
> > this issue and I'm at a bit of a loss as to what the cause could be
> >
> > One part of the app runs this: subprocess.Popen(['/usr/bin/env',
> > 'system_profiler', 'SPUSBDataType', '-xml'])
> >
> > I've never seen a problem running this, however in one users logs it's
> > returning: env: system_profiler: No such file or directory
> >
> > So I thought that maybe their PATH variable doesn't include path to the
> > binary, I asked them to provide the output of '/usr/bin/env' and 'which
> > system_profiler'
> >
> > 'which system profiler' returned '/usr/sbin/system_profiler' and
> > '/usr/sbin' was in their PATH variable that returned from /usr/bin/env, so
> > I don't really get what's going on.
> >
> > This also looks like it only happens if the user opens the .app directly,
> > but if they open the binary directly in the .app/Contents/MacOS/ folder, it
> > works and it can find these external binaries through subprocess.
> >
> > I'm really not sure what might be causing this? and I've never experienced
> > it myself when testing, nor has it ever been reported before which makes me
> > inclined to believe it's some external setting / config on the users
> > machine which is causing this behaviour?
> 
> Normally, a shell (like bash) is not involved in launching an OS X app
> bundle, like those produced by py2app, so the environment variables seen
> in an app's environment are not the same as what is seen from a terminal
> shell session.  Thus, the output of `which` and of the user's shell
> $PATH aren't relevant.   It used to be possible to influence to the
> user's GUI environment by supplying a ~/.MacOSX/environment.plist but I
> believe that is no longer supported on current OS X releases and, in any
> case, it's a bad idea to depend on it.  It is possible to include
> app-specific environment variables in the app's plist.  But, in your
> case, the simplest thing to do is use an absolute path to
> `system_profiler` and avoid use of `/usr/bin/env` within an app bundle.
> 
> 
> Ah thanks, so why does it work normally then? You say the environment is not the same, what environment is used if I open an app?

I don't know why it doesn't work on that particular machine, but what Ned wrote is correct: the Finder is started with a fairly minimal environment and does not proces shell profile files (such as .profile). AFAIK the default path should include /usr/bin and /usr/sbin.

If you really want to have the same environment as in a shell session: py2app does have an option to emulate the shell environment. The implementation of this is fairly hacky and increases startup time because it needs to fork of a shell to set up the environment.

BTW. I haven't checked if environment.plist still works, but using it shouldn't be used anyway.

What's different about the non-functional machine? Which OSX version, machine architecture, is the user account special in any way (admin account or not, parental controls, ...)?  Have you tried reporting os.environ in the application itself (and compare it with a machine that does work)?

> 
> From looking at https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/open.1.html
> 
> it says both "The open command opens a file (or a directory or URL), just as if you had double-clicked the file's icon." and "Opened applications inherit environment variables just as if you had launched the application directly through its full path." which seems to suggest that apps do have the users environment? (but if I'm running /usr/bin/env as part of the command, wont that make sure the users PATH variable is used for the command?)
> 
> I use a few different external binaries, and I'd rather not assume their location by using absolute paths, although maybe I could fallback to doing this if it fails - to be a bit safer.

Specifying the full path is saver anyway (IIRC we've had build issues in CPython when it didn't specify an absolute path for arch(1) because someone had an opensource arch command early on $PATH that wasn't compatible with the system one). Alternatively you could reset the PATH environment variable before starting the command.

> 
> Presumably I could also just pass shell=True for the subprocess call to inherit the users environment? Although that has problems of its own.

shell=True doesn't help for this, it uses /bin/sh to parse the command-line but that shell isn't started as a login shell and therefore doesn't read the shell profile

Ronald