Why do you think python (or anything else) is going to open any terminal window? And what OS are you on anyway?
For QProcess:setProgram you should have process.setProgram("python");, only. But in this case I think it's getting overridden by your process.start("python test.py"); so it doesn't matter, but it's wrong.
If you want to grab a sub-process's output, you have to handle QProcess::readyReadStandardOutput(), and in there something like QByteArray QProcess::readAllStandardOutput(), if that's what you mean by "How can I get the 'Hello' output?".
How this relates to Trying to implement thumbnail list I have no idea....
Well, actually it does work! But if bash is not running interactively, it won't read the .bashrc where the shell-variables are stored. So I did the following:
sh.start("bash -i"); // the -i tell bash to run interactively
sh.write("printenv JAVA_HOME"); // or sh.write("echo $JAVA_HOME")
In case you were wondering, I connected the QProcess::finished signal to a slot where the QProcess::readAllStandardOutput is put in a QPlainTextEdit.
The QProcess::processEnvironment is not updated however. Even if I try to export JAVA_HOME with sh.write("export JAVA_HOME"). While that is not what I expected, I now can find the local shell-variables.
I don't need Qt for this. But I have a quite large application that does a lot of things. One of those, is to launch external applications and send them keystrokes as you would type in front of a keyboard.
Of course you should always be careful with sudoers, but even more so when using wildcards.
That's good advice and only to throw my 2 cents in:
Allowing users to change system-wide settings somehow defeats the whole point of having users in the first place. What happens if one user changes the timezone, but another is not happy with that and changes it back? These are system changes we're talking about, so that's one good reason for actually having a super user that manages them ...
Thanks for your response. The whole body of code is proprietary so I'm not sure I can share it in a public forum.
However I can make a note that it used to work fine a month ago and after that no changes occurred to this code and no qt libraries were replaced, so the issue is like to be caused by hardware malfunction.
Such a strong word ... it depends on the advisory locking mechanism used and most linux-es will support more than one. As duly noted in the documentation it's only guaranteed to work if the same scheme is used across all processes:
Serialization is only guaranteed if all processes that access the shared resource use QLockFile, with the same file path.
Does seem implementing the startDetached() is the better option ( if i understand correctly) as when the app closes , closing down the started sup processes could be problematic.
On a side note:
Needing to keep the instance around is also an interesting complexity, if logic serves,
The app starts a process (perhaps stored in a QList Or QHash)
Maintain the state so when the sup-process terminates i can ether re-use the process or remove the process and create another instance .
*with the understanding that if the main app closes all sup-process's will close.
First, you have to understand that QProcess is running asynchronously. That means that in your two lines containing a start call, your second start is not waiting for the first process to stop.
In particular, you have the finished signal that tells you when the process is done. From that you can connect a slot that will start your second process, here the "route" process.
If you have a lot of processes to run in a row, I think you could add them to a QQueue member variable. Then, connect your QProcess finished signal to a custom slot that will start the next process until the QQueue is empty. You can also handle errors and decide what to do if anything wrong happens.