To follow up on this thread…

On OS X, running PV as an app, then opening the Python shell, I get:
>>> os.environ
{'SHELL': '/bin/bash', 'SSH_AUTH_SOCK': 
'/private/tmp/', 'XPC_FLAGS': '0x0', 
'__CF_USER_TEXT_ENCODING': '0x1F5:0x0:0x0', 'Apple_PubSub_Socket_Render': 
'/private/tmp/', 'LOGNAME': 'heiland', 
'USER': 'heiland', 'XPC_SERVICE_NAME': 'org.paraview.ParaView.37836', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/Users/heiland', 'DISPLAY': 
'/private/tmp/', 'TMPDIR': 

however, running it as:
/Applications/$ ./paraview 
the os.environ spews ALL envs in my bash shell.

If there’s another option, outside of using env vars, for dynamically getting a 
user-defined string inside a Programmable Source, I’d welcome it.


> On Dec 21, 2017, at 3:31 PM, Ben Boeckel <> wrote:
> On Thu, Dec 21, 2017 at 15:14:01 +0000, Heiland, Randy wrote:
>> Thanks Ben.  You’re right, of course. Moreover, my idea for having
>> (non-admin) users install additional Python modules (e.g., scipy) into
>> PV’s dir, is a not going to go well.
> Well, if `sys.path` or `PYTHONPATH` can be pointed to it, it *should*
> work (though the `numpy` in the package may not be configured properly
> for `scipy`).
>> Do we at least agree that if I ask users to start PV from the
>> Terminal, PV’s Python will then pick up the user’s env vars?
> It should, but ParaView doesn't do anything to stop it. If it doesn't
> work, it's probably some Apple framework thing that needs to be told not
> to do silly things.
> --Ben

Powered by

Visit other Kitware open-source projects at

Please keep messages on-topic and check the ParaView Wiki at:

Search the list archives at:

Follow this link to subscribe/unsubscribe:

Reply via email to