QProcess vs K3Process
thiago at kde.org
Mon May 28 21:24:16 BST 2007
Oswald Buddenhagen wrote:
>> Ack. This is a good idea. Probably kutils, though, since we already
>> have a library for that extra stuff.
>uhm, maybe. note that this will pull in libutil and libutempter, though.
I don't think it's a problem for libkutils. It's very far down the chain.
Not many things use that library anyways.
>> I.e., if you just want add one variable and remove another, you would
>> do: QMap<QString,QString> environment = QProcess::systemEnvironment();
>> environment["LD_LIBRARY_PATH"] = "Foo";
>> QProcess proc;
>yes ... well, for practical reasons a setEnv()-type api is still best.
Maybe, but I think manipulating the environment directly with a variable
(map or list) is easier.
Then again, if we start adding more stuff (setCurrentWorkingDir,
setFrobnicator, etc.), it would be nice to have a setEnvironment too,
even if just for symmetry/consistency purposes.
>> Do you mean here a setCommandLine()-like call?
Agreed then, at least for consistency then.
>> Which is why setUseShell shouldn't be there. It won't behave the same.
>which is why i said "user-supplied". ;)
>> If you know your program will run only on Unix, you can use:
>> start("sh", QStringList() << "-c" << "mycommand | pipe |
>which is sort of the same, just less convenient ...
Indeed, but it's the price to pay for using a shell. At least in this case
the user is under no impression that his code is portable. We're forcing
him to realise that.
I'd say setUseShell should stay away.
>> > - qproc does not allow handling only one of stdout/stderr (ttt
>> > 131926). kproc could work around this by playing a proxy for the
>> > unhandled channel. when qprocess gains the feature, the kproc api
>> > would become a trivial wrapper.
>> Agreed. This should be done at QProcess level.
>do you think i should go for the intermediate solution now? or wait for
>qt 4.4 => kde 4.1? as mentioned before, right after the kde 4.0 release
>we will need useful .xsession-errors most ...
If you can do this without too much hackery for KDE 4.0/Qt 4.3, it would
be nice. Otherwise we'll convince the trolls and have it for 4.4.
>> That might be so, but it's also too late to change QProcess
>yes, but we can override them. but this is inconsistent => problematic,
>so i would not do it unless we want to "hide" QProcess entirely - which
>isn't a problem, if you ask me.
Same here. It's not unprecedented.
>> >- qproc' startDetached() and execute() are statics.
>> > parametrization-wise, this doesn't scale at all. execute() is no
>> > problem, as it is trivial. startDetached() *is* a problem - and not
>> > fixable in kproc. ttt 131923.
>> This would be a nice addition to QProcess's API. However, if you
>> startDetached (non-static), your object's state hasn't changed. The
>> QIODevice doesn't open. No signals will ever be emitted.
>that's sort of right. you'd only get a bool from the function itself and
>possibly an error() emission.
>> What's the point in having the non-static version?
>hey, read more carefully. ;)
Understood. I agree now on a non-static startDetached().
>> >- qproc cannot join the (output) channels of multiple processes. not
>> > fixable in kproc. ttt 131901.
>> > this is from the "get rid of setUseShell" camp. not critical.
>> This is possible.
>> # shell: foo > bar.txt 2>&1
>> QProcess proc;
>> proc.setStandardOutputFile( "/bar.txt" );
>> Or did I misunderstand you?
>yes. i said "multiple processes". we discussed this already at length -
>i'm sure you'll remember again after some warmup. :)
Then it isn't the bug report you mentioned. The shell command that you
provided is already allowed.
If you mean:
(foo; bar | baz) 2>/bar.txt
kind of stuff, I'm still a bit skeptical. When I added the piping between
process feature in QProcess last year, I discussed this with you and I
thought it was far too specific to warrant support. Especially if it's
complex to implement.
>> >- qproc does not support process groups/jobs.
>> I have to see a use-case for this first.
>this is the logical continuation of setStandardOutputProcess().
>the example i sent to tt goes like this:
>QProcess p1, p2;
>whether we actually need system level process groups is another
>question - but being able to "kill -TERM -<group leader>" sure would not
That sounds like a nice API, but why would we want it in Qt or even in
I understand what it would do, but what's the actual use-case for this in
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel