Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QProcess keep env with external program
I'm using Qt4.8.5. I have a pretty common request on a use case yet I'm unable to find any clue within the first 3 pages of google search result.
The request is to reserve the env setting for consequent QProcess call.
This is because our env setting is too complicated to be equally set with QProcessEnvironment,
So what I need is : how can 'real_cmd' inherit the env setting initialized by 'init_env' ?
QProcess *p = new QProcess(this); p->start("source init_env"); // env is set here p->start("real_cmd"); // how to reserve the env setting for real_cmd ?
You should take a look at QProcess::setProcessEnvironment
qt_fan_4k last edited by qt_fan_4k
Thank you for the answer, SGaist, as ever. You are the most helpful guru in the forum.
I might have not stated my question clearly.
I thought about setProcessEnvironment, but it couldn't meet my requirement.
In my question : our env setting is too complicated to be equally set with QProcessEnvironment, i.e., to set all the env name/value pairs.
We have an existing script to do all the stuff, collecting all configuration and initializing the env properly.
It would be best if I can simply 'source' this script with QProcess and every consequent command called by QProcess can inherit the env setting.
In short, how can I setenv by calling external program rather than calling setProcessEnvironment, which would be too complicated to reimplement.
bsomervi last edited by
You need to have the process run a command shell since that is what processes you environment setup commands. Your problem then becomes portability since the command shell program is unlikely to be the same on each platform. Your process command then becomes
"sh -c 'source init_env ; real_cmd'"or similar.
Can't you read them from that file ?
Otherwise, you could also wrap the call to your application in a script that would setup the environment and call that script from QProcess.
About the portability, the init_env will act as an adapter, leaving my Qt program independent of the running platform.
I also thought about combining the init cmd and real_cmd in a single short, like '&&', but that leads to portability issue, and what makes matters worse is that I have to call init_env every time prior to launching an external program.
T?his is not acceptable, because the init_env is very complicated and time-consuming.
Unfortunately the init_env is not a plain text that can be parsed with reasonable cost.
This complicated script collects env setting from a great variety of locations under complicated conditions.
I'd like to use the QProcess as if a shell to the user, i.e., I don't know real_cmd in advance. The user can call any program with my Qt program and that's why I can't wrap the program with init_env, and if I wrap every command with init_env, calling init_env every time for any external program adds too much runtime overhead.
But there might be a solution which is not elegant enough:
I may wrap init_env with a script, which dump all system env into an intermediate file after init, and use SetProcessEnvironment to load that intermediate file, to init env for following command calls, but I think there should be something better in Qt.
Rather than dump in a file, dump in std out and use QProcess to parse/retrieve these information. You also have qgetenv to retrieve environment variables in your software.