QProcess vs K3Process

[Thiago Macieira]

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";
>>   environment.remove("LD_PRELOAD");
>>   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?
>
>yes.

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 |
>> whatever");
>
>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
>> defaults...
>
>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. ;)
[snip]

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" );
>>  proc.setProcessChannelMode(QProcess::MergedChannels);
>>
>> 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;
>p1.setProgram("ls");
>p2.setProgram("less");
>p1.setProcessGroupLeader();
>p2.joinProcessGroup(&p1);
>p1.setStandardOutputProcess(&p2);
>p1.start();
>
>whether we actually need system level process groups is another
>question - but being able to "kill -TERM -<group leader>" sure would not
>hurt. :)

That sounds like a nice API, but why would we want it in Qt or even in 
KDE Libs?

I understand what it would do, but what's the actual use-case for this in 
KDE?

-- 
  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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070528/31f8149f/attachment.sig>