[Pythonmac-SIG] Environment variable issues running py2app application

[Paul Wiseman]

On 25 April 2013 13:08, Ronald Oussoren <ronaldoussoren at mac.com> wrote:

>
> 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)?
>
>
I'm not sure what's different about this machine, it's running 10.8.3 but
it works just fine on other 10.8.3 machines. I'm not too sure what the
machine architecture is, I logged everything callable in the platform
module (pasted below) from inside the app and I can see i386 and x86_64. I
guess it's the latter though. I've asked the user to provide a bit of
information about the account, parental controls etc, is there a way to get
this info from python? I will add os.environ into the logging, so I'll have
that information in future - that's a pretty good idea :) I'd forgotten all
about it.

_mac_ver_gestalt: ('10.8.3', ('', '', ''), 'i386')
_mac_ver_xml: ('10.8.3', ('', '', ''), 'x86_64')
_node: ###-MacBook-Pro.local
_sys_version: ('CPython', '2.7.4', '', '', 'v2.7.4:026ee0057e2d', 'Apr  6
2013 10:15:50', 'GCC 4.0.1 (Apple Inc. build 5493)')
_syscmd_ver: ('', '', '')
architecture: ('32bit', '')
dist: ('', '', '')
java_ver: ('', '', ('', '', ''), ('', '', ''))
libc_ver: ('', '')
linux_distribution: ('', '', '')
mac_ver: ('10.8.3', ('', '', ''), 'x86_64')
machine: x86_64
node: ###-MacBook-Pro.local
platform: Darwin-12.3.0-x86_64-32bit
processor:
python_branch:
python_build: ('v2.7.4:026ee0057e2d', 'Apr  6 2013 10:15:50')
python_compiler: GCC 4.0.1 (Apple Inc. build 5493)
python_implementation: CPython
python_revision:
python_version: 2.7.4
python_version_tuple: ('2', '7', '4')
release: 12.3.0
system: Darwin
uname: ('Darwin', '###-MacBook-Pro.local', '12.3.0', 'Darwin Kernel Version
12.3.0: Sun Jan  6 22:37:10 PST 2013;
root:xnu-2050.22.13~1/RELEASE_X86_64', 'x86_64', '')
version: Darwin Kernel Version 12.3.0: Sun Jan  6 22:37:10 PST 2013;
root:xnu-2050.22.13~1/RELEASE_X86_64
win32_ver: ('', '', '', '')


 >
> > 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.
>
>
Maybe I will just use absolute paths, I guess it's unlikely that someone
would move the binaries somewhere else, that's still in the PATH. I guess
these binaries have always been in the same place 10.4-10.8? as I'll be
targeting all these users

To reset the path, would I just update the PATH entry in the os.environ
dict? Presumably I could just add /usr/bin:/usr/sbin to the start of PATH
when the app starts up, then I should be ok?


> >
> > 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
>
>
Ah thanks, I didn't realise that. I always presumed it was the same as
running it in a terminal window or the like - guess I was wrong!


>  Ronald
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20130425/b44fa85f/attachment-0001.html>