On 24 April 2013 19:29, Ned Deily <n...@acm.org> wrote: > In article > <cacgdh2jujjuvuekoxpr2e4utje3zdyad8ox9jcffplhghbx...@mail.gmail.com>, > Paul Wiseman <poal...@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?
>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. Presumably I could also just pass shell=True for the subprocess call to inherit the users environment? Although that has problems of its own. > -- > Ned Deily, > n...@acm.org > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG@python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG >
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG