Proper usage of the `ExecuteEnv` parameter for `wx.Execute`?

#1

Hello,

I have a wxPython app which spawns child processes using the wx.Execute command and wx.Process class, this works as expected. However, I also need to pass along additional environment parameters to indicate the working directory for the child process. The option seems available though the ExecuteEnv parameter as indicated by the documentation for wx.Execute (see below).

An optional pointer to additional parameters for the child process, such as its initial working directory and environment variables. This parameter is available in wxWidgets 2.9.2 and later only.

However, I cannot figure out how to use ExecuteEnv in this context to get the desired effect. I’ve tried instancing it but an error is raised indicating that it’s not possible. I tried passing arguments over using a dict assuming the function takes keyword arguments similar to Popen, however that doesn’t work.

This is how I’m presently calling wx.Execute:

ret_val = wx.Execute(command, flags, process)

Here is what I tried with ExecuteEnv:

env = wx.ExecuteEnv()  # error, cannot be instanced but present in the library
env["cmd"] = "path/to/working/dir"  # perhaps it was suppose to work like this? doesn't though ...

# tried it even like this, but also doesn't work
# wx.ExecuteEnv["cmd"] = "path/to/working/dir" 

ret_val = wx.Execute(command, flags, process, env)  # passing the environment params this time

Any suggestions or workarounds to specify the working directory (or environment) for the child process?

Thank you.

#2

Unfortunately, it appears that wx.ExecuteEnv isn’t wrapped, so it seems that you cannot use the env parameter of wx.Execute currently.

As a workaround, you could perhaps use the subprocess module in the standard library?

1 Like
#3

As already pointed out, subprocess is the way to go…
or, just have your child process learn about its own environment by reading from a configuration file instead.

1 Like
#4

just have your child process learn about its own environment by reading from a configuration file

Can’t in this case as I don’t have much control over that end.

As a workaround, you could perhaps use the subprocess module in the standard library?

Bit of a shame to go this route again, the wx library allowed for non-blocking pipe reads without having to deal with threading and supported event bindings. Hope this gets sorted out someday.

1 Like